DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0031] Described herein is an extensible directory service which includes multiple, distinct services running on separate groups of application servers. Although the directory service is described with reference to a preferred embodiment of a distributed on-line services network, it will be apparent to those skilled in the art that various aspects of the directory service are applicable to other types of computer networks and network configurations.

[0032] For convenience, the description of the preferred embodiment is arranged within the following eleven sections:

[0033] 1. ARCHITECTURAL OVERVIEW (FIG. 1);

[0034] 2. OVERVIEW OF DIRECTORY SERVICE AND RELATED COMPONENTS (FIGS. 1-3);

[0035] 3. CLIENT-SERVER ARCHITECTURE OF DIRECTORY SERVICE (FIG. 4)

[0036] 4. REPRESENTATION OF NODE PROPERTIES (FIG. 5);

[0037] 5. NODE DISK STRUCTURES (FIG. 6);

[0038] 6. SHABBIES (FIG. 7);

[0039] 7. SERVER MEMORY STRUCTURES AND OPERATION (FIGS. 8 AND 9);

[0040] 8. JUNCTION POINTS (FIGS. 10A AND 10B);

[0041] 9. TREENAV METHODS;

[0042] 10. LOCALES AND ACCESS RIGHTS FILTERING OF NODES (FIG. 11); and

[0043] 11. OTHER EMBODIMENTS.

[0044] The first of these sections provides an architectural overview of the preferred on-line services network in which the present invention is embodied. The architecture of this network is further described in the above-referenced application having the title “ARCHITECTURE FOR SCALABLE ON-LINE SERVICES NETWORK” (U.S. Ser. No. 08/472,807), which is incorporated herein in by reference.

[0045] Throughout the following description, the first letters of the names of specific services on the network will be capitalized (for example, “Chat,” “BBS,” and “Directory Service”). Additionally, the names of specific software methods and interfaces will be provided in mixed case (for example, “GetChildren,” “GetAccountRights” and “TreeNav.”)

[0046] 1. Architectural Overview (FIG. 1)

[0047] FIG. 1 is a high-level diagram illustrating the general architecture of an on-line services network 100 which provides a directory service in accordance with the present invention. Multiple client microcomputers 102 are connected to a host data center 104 by a wide area network (WAN) 106. The wide area network 106 includes WAN lines 108 which are provided by one or more telecommunications providers, and which allow end users (i.e., users of the microcomputers 102) over a wide geographic area to access the host data center 104. The WAN lines 108 preferably include both X.25 lines and ISDN (Integrated Service Digital Network) lines. The host data center 104 provides a variety of information-related and communications-related on-line services to end users.

[0048] The host data center 104 comprises a plurality of application servers 120 connected to one or more high speed local area networks (LAN) 122. The application servers 120 are preferably Pentium-class (or better) microcomputers which are scalable to at least four central processing units (CPUs), and which run the Microsoft Windows NT operating system available from Microsoft Corporation. Each application server 120 typically has at least 128 MB of random-access memory (RAM) and at least 4 GB of disk space.

[0049] The application servers 120 are arranged into service groups (also referred to as “AppGroups”) that correspond to specific on-line services. Three example service groups are shown in FIG. 1: a Chat service group 130, a Bulletin Board System (BBS) service group 134, and a Dirsrv service group 132. Additional service groups (not shown) are provided to implement other on-line services, including a Mediaview service which provides multimedia titles to end users, a mail service, a Component Manager service which allows users to update client software when new releases become available, and a File Transfer Manager (FTM) service. Other on-line services may include, for example, an interactive games service, a weather service, and a World Wide Web browsing service. A service group can have as few as one application server 120. System administrators can adjust the number of application servers 120 in a given service group to accommodate the current usage level of the corresponding service. For example, application servers 120 can be added to the BBS service group 134 to increase the user capacity of the BBS service.

[0050] Also connected to the LAN 122 are multiple Gateway microcomputers 140 (hereinafter “Gateways”) which link incoming calls from end users to the application servers 120. The Gateways 140 are preferably Pentium-class microcomputers which are scalable to at least four CPUs, and which run the Microsoft Windows NT operating system. Each Gateway 140 typically has at least 64 MB of RAM and at least 2 GB of disk space, and is capable of supporting approximately 1000 simultaneous user connections.

[0051] Also connected to the LAN 122 are multiple security servers 150. The security servers 150 are preferably Pentium-class microcomputers which are scalable to at least four CPUs, and which run the Microsoft Windows NT operating system. Each security server 150 maintains a relational database 152 which contains the access rights data for all users of the network 100. Each security server 150 runs Structured Query Language (SQL) code to provide access to its respective access rights database 152. SQL is a language standardized by the International Standards Organization (ISO) for defining, updating and querying relational databases. A query to the access rights database 152 can emanate either from one of the application servers 120 (when, for example, a user attempts to access a content entity which is stored by the application server 120), or by one of the Gateways 140 (when a user attempts to open an on-line service). Each machine 120, 140 which generates queries of the access rights databases 152 preferably implements an access rights cache for locally storing user-specific access rights information obtained from the database 152.

[0052] Various other types of servers and other microcomputers are connected to the LAN 122 but are not shown in FIG. 1. For example, billing and logon servers are provided to record billable events and to handle user logon, respectively. Further, Arbiter microcomputers are provided to perform transaction replication services for certain service groups (including both the Dirsrv service group 132 and the BBS service group 134), allowing the application servers 120 of such service groups to store identical copies of the same service content data.

[0053] It is envisioned that the host data center 104 may have on the order of one hundred Gateways 140, and between several hundred and several thousand application servers 120. A host data center of this type will be able to handle millions of subscribers and tens of thousands of simultaneous user logon sessions. Advantageously, the processing capacity of the host data center 104 can easily be increased (to support new services, and to support increases in the number of subscribers) by connecting additional Gateways 140 and application servers 120 to the LAN 122, and by adding additional local area networks. Further, additional host data centers 104 can be provided at different geographical locations to accommodate a wide geographic distribution of subscribers.

[0054] The on-line services offered to end-users of the network 100 are preferably in the form of client-server application programs or “service applications”. Each service application includes a server portion that runs on one or more of the application servers 120, and at least one corresponding client portion (also referred to as a “client application” or “client”) that runs on a microcomputer 102 of an end user. In the presently preferred embodiment, the client applications are in the form of Microsoft Windows 95 executables, and the server portions are implemented as dynamic link libraries running under the Microsoft Windows NT operating system.

[0055] With reference to FIG. 1, the server portions of the various on-line services are implemented on the application servers 120 of the respective service groups 130, 132, 134. Each application server 120 of a given service group separately runs the same server application. For example, each application server 120 of the Chat service group 130 runs CHAT.DLL, which is a dynamic link library that implements the server portion of the Chat service. Similarly, each application server 120 of the BBS service group 134 runs a BBS dynamic link library, and each application server 120 of the Dirsrv service group 132 runs a Dirsrv dynamic link library. Although each application server 120 is shown in FIG. 1 as being allocated to a single service group, a single application server can simultaneously run multiple service applications, and can thus be allocated to multiple service groups. For example, a single application server 120 could run both the Chat and BBS dynamic link libraries and thus be allocated to both the Chat and BBS service groups 130, 134.

[0056] During a typical logon session, a client microcomputer 102 will maintain a communications link with a single Gateway 140, but may access multiple on-line services (and thus communicate with multiple application servers 120). To initially access a service, an “open” request is generated on the client microcomputer 102 and sent to the Gateway 140 that is handling the logon session. The Gateway 140 then selects a single application server 120 (of the appropriate service group) to handle the service session, and opens a pipe (e.g., a TCP/IP connection) over the LAN 122 to the selected application server 120.

[0057] Throughout the service session, the Gateway 140 routes messages between the client microcomputer 102 and the application server 120 as the client and server portions of the service application communicate. The Gateway 140 also performs protocol translation between the protocol of the WAN 106 and the protocol of the LAN 122. To terminate the service session, a “close” request is generated on the client microcomputer 102 and sent to the Gateway 140, and the Gateway 140 closes the pipe to the application server 120 that is handling the service session.

[0058] The architecture advantageously supports multiple simultaneous service sessions per user. Thus, a user may be connected to multiple applications servers (via the Gateway 140 handling the logon session) simultaneously.

[0059] Two specific on-line services, Chat and BBS, will now be briefly described. This description will illustrate some of the specific types of content entities (referred to herein as “content objects,” or simply “objects”) which may be accessed by users.

[0060] The Chat service is an interactive communications service which allows users to have real time conversations with other users on specific topics. Chat conversations or “conferences” are organized as “Chat rooms” which may be entered or exited by end users to join or leave the corresponding conferences. For example, an end user may enter a “sports” Chat room to join an interactive conversation on sports-related topics. Participants in a Chat conference can type in textual messages which will be displayed on the monitors of other participants. Voice and/or video capabilities may additionally be provided.

[0061] The BBS service allows users to post and/or review messages. Users can thereby ask and answer questions, or otherwise conduct non-real-time conversations with other users. Although shown as a single BBS service group 134 in FIG. 1, multiple BBS service groups may be formed, with each corresponding, for example, to a particular topical area. In the preferred implementation depicted by FIG. 1, replicated copies of all BBS content (e.g., BBS messages and folders) are stored on each application server 120 of the BBS service group 134. This allows the BBS application servers 120 to independently process message read requests from end users. Replication of BBS content is accomplished using the Arbiter transaction replication service. A preferred embodiment of the Arbiter service is described in commonly-assigned copending U.S. application Ser. No. 08/485,493, filed Jun. 7, 1995, having the title TRANSACTION REPLICATION SYSTEM AND METHOD FOR SUPPORTING REPLICATED TRANSACTION-BASED SERVICES, which is incorporated herein by reference.

[0062] With reference to FIG. 1, one of the application servers 120 of the BBS service group 134 is preferably configured as an Internet feed server 120. The BBS Internet feed server 120 reads Internet newsgroup messages and posts these messages (by submitting update transactions to the Arbiter service) within the BBS service group 134, thereby providing users with access to such newsgroup messages. The BBS Internet feed server 120 is also used to post messages to the Internet.

[0063] Chat rooms and BBS messages are two types of content objects that may be accessed by users. The ability to access a given content object, and the access rights of the user with respect to that object, may vary from user to user. Using a Chat room object as an example, some users may be “participants” who can participate in the conference, while other users may be “viewers” who can only view the text of the conversation. One or more users may further be designated as a “host” of the conversation. A host normally has the responsibility of moderating the conversation, and has the ability to modify the access rights of members of the conversation with respect to the Chat room.

[0064] 2. Overview of Directory Service and Related Components (FIGS. 1-3)

[0065] The Directory Service is an extensible on-line service that contains databases which describe the various content entities (i.e., the on-line services and associated data entities) of the network 100 that are accessible to users. Access to these databases is provided via navigation and edit application program interfaces (APIs) of the Directory Service. Through these interfaces, users are provided with a hierarchical, navigable view of the various content objects available on the network 100, and are provided with a mechanism for accessing the content objects.

[0066] The Directory Service is advantageously distributed among different on-line services, which are referred to herein as “Directory Service Providers.” Each Directory Service Provider provides a directory to a subset of the content of the network 100. In a presently preferred implementation described herein, the Directory Service is implemented by two Directory Service Providers, the Dirsrv service and the BBS service. As will be apparent from the description that follows, however, the Directory Service supports the addition of an indefinite number of other Directory Service Providers. Accordingly, the preferred embodiment will be described herein in terms of both (1) an extensible Directory Service architecture which supports an indefinite number of Directory Service Providers, and (2) a two-Directory-Service-Provider implementation of the Directory service.

[0067] Each Directory Service Provider maps its content into a hierarchical directory structure, which is stored within a corresponding “provider namespace.” In accordance with one aspect of the present invention, a seamless interface is provided to allow the user to transparently move from one directory structure to another, so that the multiple directory structures (of the multiple Directory Service Providers) appear to the end user as a single directory structure, and so that the Directory Service appears as a single service. This feature of the invention is described in detail below.

[0068] With reference to FIG. 1, the Directory Service (abbreviated as “DS” in FIG. 1) includes the Dirsrv service (implemented on the Dirsrv service group 132) and the BBS service (implemented on the BBS service group 134). The Dirsrv service is the “root” of the Directory Service, and provides users with a hierarchical, navigable view of all non-BBS content objects (such as Chat rooms and Mediaview titles). The BBS service provides users with a hierarchical, navigable view of all BBS content objects.

[0069] With reference to FIG. 2, which illustrates the general organization of content objects as maintained by the Directory Service, each Directory Service Provider maintains a respective directory structure 202, 204 that represents a hierarchy of content objects. Each directory structure 202, 204 is comprised of multiple interconnected nodes, with each node representing a corresponding content object (or collection of content objects) which may be accessed via the corresponding Directory Service Provider. The Dirsrv directory structure 202 is stored within a Dirsrv namespace 212, and is stored on the application servers 120 of the Dirsrv service group 132. The nodes of the Dirsrv directory structure 202 represent the content objects which may be navigated and accessed via the Dirsrv service. The BBS directory structure 204 is stored within a BBS namespace 214, and is stored on the application servers 120 of the BBS service group 134. The nodes of the BBS directory structure 204 represent the content objects which may be navigated and accessed via the BBS service.

[0070] The Dirsrv and BBS namespaces 212 and 214 are both “provider namespaces.” As described below, a seamless interface between the Dirsrv and BBS services allows users to transparently traverse between the two directory structures 202, 204, so that the Directory Service appears as a single service to end users, and so that the two directory structures 202, 204 are seen by users as a single tree-like directory structure.

[0071] Advantageously, additional Directory Service Providers (and additional provider namespaces) can be added to the Directory Service. For example, an investment service that provides data on stocks and mutual funds could be added which acts as a Directory Service Provider with respect to its own content, and this content would be stored within a separate directory structure that is linked to the other directory structures 202, 204. The investment service would preferably be implemented on its own, separate group of application servers 120.

[0072] As will be apparent from the following description, the addition of new Directory Service Providers increases the content capacity (i.e., the total number of nodes which can be stored) of the Directory Service. In addition to this ability to increase the content capacity of the Directory Service, the capacity of a given Directory Service Provider to service users can advantageously be increased by the addition of application servers 120 to the corresponding service group.

[0073] In accordance with one aspect of the present invention, the Directory Service is accessed via a navigation API, referred to herein as the “TreeNav” API, and via an edit API, referred to herein as the “TreeEdit” API. These APIs may be implemented in whole or in part by the different Directory Service Providers. As will be apparent to those skilled in the art, the provision of the TreeNav and TreeEdit APIs greatly facilitates the addition of new Directory Service Providers, and thereby provides for a high degree of extensibility.

[0074] With further reference to FIG. 2, each directory structure 202, 204 may have thousands of nodes, and could thus represent thousands of content objects. The nodes can generally be thought of as “service areas” that can be entered by users. Links between nodes represent paths that can be taken by users in traversing the hierarchical structures 202, 204 from one service area to another. The specific nodes and links shown in FIG. 2 are provided to show the general manner in which nodes are arranged, and do not represent an existing directory structure.

[0075] In accordance with the present invention, the Directory Service Providers are free to use any database arrangement for the storage of their respective nodes. In the preferred embodiment, the Directory Service Providers store their respective nodes as node files of a filesystem, with each node file containing a list of node properties that represents a single node. Various other database arrangements are possible. For example, a Directory Service Provider could be configured to store its nodes within an SQL (Structured Query Language) database.

[0076] The hierarchical directory structures 202, 204 are preferably in the form of directed acyclic graphs. As is well known in the art of file systems, a directed acyclic graph structure is more flexible than a strict tree structure, since a directed acyclic graph allows a node to have multiple parent nodes. (A “parent” of a given node is any node that is both (1) directly connected to the given node, and (2) at a higher level in the hierarchy than the given node. Similarly, a “child” is any node that is both (1) directly connected to the given node, and (2) at a lower level than the given node.) This characteristic of the directory structures 202 and 204 is illustrated by nodes 7 and 13, each of which has two parent nodes. In other embodiments of the invention, a strict tree structure may be used.

[0077] With reference to FIG. 2, the extensible, composite structure 220 formed by the two directory structures 202 and 204 (and other directory structures which may be added) will be referred to herein as the “content tree.” This use of the term “tree,” however, is not intended to suggest that the composite structure 220 is a strict tree structure.

[0078] As will be appreciated by those skilled in the art, the provision for multiple Directory Service Providers that are seamlessly linked to one another advantageously allows the task of providing a directory service to be distributed among multiple, different services. This is particularly advantageous when the volume of the content on the network 100 is sufficiently high such that a single service cannot efficiently store and provide access to all node. Conversely, the ability to distribute the Directory Service among a variable number of services enables the content tree 220 to be expanded (by the addition of new nodes) without a corresponding degradation of performance.

[0079] As will further be appreciated, because different Directory Service Providers store and provide access to different types of nodes, each Directory Service Provider can be tailored to the specific requirements of the type or types of nodes stored by that Directory Service Provider, without concern for the specific requirements of other types of node. By way of specific example, only the BBS service needs to include code for monitoring and deleting old BBS message nodes, since the BBS service is the only Directory Service Provider that stores BBS message nodes. This feature of the present invention will be apparent from the description that follows.

[0080] In the preferred embodiment, the content tree 220 is displayed to the end user via a network shell application which runs on the client microcomputers 102 of end users. The network shell is the primary client of the Directory Service. A preferred implementation of the network shell is described in a commonly-assigned U.S. application having the title ON-LINE NETWORK ACCESS SYSTEM, filed Jul. 17, 1995, which is incorporated herein by reference. In the preferred embodiment, the network shell is an integral part of the Microsoft Windows 95 Explorer program (hereinafter “the Explorer”), which is described in Inside Windows 95, Microsoft Press, 1994. As will be apparent to those skilled in the art, other types of shell applications could be used. As described below, a graphical user interface of the Explorer displays the content objects as a logical extension of the user's hard drive, with nodes represented by corresponding icons on the user's screen.

[0081] In accordance with the present invention, the content tree 220 includes three different types of nodes: leaves, folders and junction points. A set of flags stored in association with each node identifies the node as one of these three types. Leaves (or “leaf nodes”) are nodes that both (1) cannot have children and (2) do not serve as junction points. The leaf nodes in FIG. 2 are nodes 4-7, 12 and 13 (assuming that these nodes cannot have children). Leaves represent the actual services within network 100. Examples of leaves include Chat rooms, BBS messages, Mediaview titles and download-and-run files. When the user clicks on a leaf node (by double clicking on the double corresponding icon from a window of the Explorer), the corresponding service-related action is taken. For example, if the user double clicks on a Chat room icon, the Chat service is opened and the user is added to the corresponding Chat conference. When the user double clicks on an icon for a download-and-run file, the file is downloaded to the user's computer 102.

[0082] Folders are nodes that both (1) can have children, and (2) do not serve as junction points. The folder nodes in FIG. 2 are nodes 0-3 and 9-11. Folder nodes normally represent collections of other content objects, and are used to organize the content of the network. For example, a folder node may correspond to a BBS folder on a particular topic, or may represent a collection of BBS folders and Chat rooms on a related topic. Folder nodes are also used to generally arrange content objects according to language. For example, node 1 may be an english folder containing content objects that are primarily in english, and node 2 may be a spanish folder containing content objects that are primarily in spanish. Folder nodes are generally analogous to the directories of a file system.

[0083] Junction points are nodes that serve as proxies for nodes in other provider namespaces and that allow the user to seamlessly traverse between provider namespaces. The only junction point shown in FIG. 2 is node 8, which serves as a proxy for BBS folder node 10 (referred to as the “target node”). When, for example, the user double clicks on node 8, the Explorer launches a BBS navigator and shows the user the children of node 10. Although only a single junction point is shown in FIG. 2, many junction points may be provided within the content tree 220. Junction points are discussed in detail below under the heading JUNCTION POINTS.

[0084] With reference to FIG. 3, a graphical user interface of the Explorer displays the content tree 220 as a logical extension of the user's hard drive. In the window configuration shown, the left-hand window pane 302 displays a hierarchical map 304 of folder nodes, and the right-hand window pane 308 displays the icons 310 and names 312 of the content objects within a selected folder node. The hierarchical map 304 corresponds to a portion of the content tree 220. In the example shown in FIG. 3, the map 304 includes three folder nodes with names of “categories (US),” “Member Assistance (US),” and “Favorite Places,” and the right-hand window pane 304 displays the contents of the “Categories” folder (which has been selected by the user from the left-hand pane 302).

[0085] Using the Explorer, users can browse the content tree 220 and can access the various content objects. Various actions are available to the user to reveal different levels of nodes. For example, the user can click on a folder displayed in the left pane 302 to “expand” the folder, or can click on a “parent folder” button (not shown) to move upward through the content tree. To access a content object (to, for example, enter a specific on-line service), the user can double click on the icon for that object. Because the content tree 220 is preferably structured as an acyclic graph, the user may take different paths to get to the same content object. The particular actions which can be performed by a user upon accessing a node depend upon the user's access rights with respect to the node, which are stored within the access rights databases 152 on the security servers 150. Access rights of users can advantageously be specified within the database on a single-user basis.

[0086] In accordance with one aspect of the present invention, the Directory Service only “shows” to each user those nodes that the user is authorized to access, or equivalently, those nodes to which the user has access rights. (In the preferred embodiment, the lowest level of access rights a user can have at a node is “viewer-only.” A user with viewer-only level access rights at a node can view certain properties of the node, but cannot either modify the properties or open the corresponding service.) Thus, each user is provided with a filtered view of the actual content of the network 100, seeing only the icons of the nodes that the user is authorized to view or otherwise access.

[0087] This feature of the invention advantageously allows certain nodes and content objects to be completely hidden from certain classes of users. For example, this feature may be used to hide from the view of regular users a BBS folder (and its contents) that has been created for private correspondence between members of a family, so that the only users who can see the folder from the Explorer are the designated family members. Because only those authorized to access each node can see the node, a high degree of security is provided against unathorized accesses.

[0088] In the preferred embodiment, a Sysop Tools client application (which is preferably integrated with the Explorer) allows authorized end users to remotely edit the content tree 220. Edits to the content tree can also be made locally (i.e., from within the host data center 104) by system administrators. Edits to the content tree 220 are made via the methods of the TreeEdit API, which are implemented by the various Directory Service Providers. These methods include methods for adding and deleting nodes, and for editing the properties of existing nodes. The capability of a user to edit the content tree 220 is specified by the user's access rights. To determine the access rights of users, the Directory Service Providers generate user-specific queries of the access rights database 152 (using a GetAccountRights API, as described below under the heading LOCALES AND ACCESS RIGHTS FILTERING OF NODES).

[0089] Users that have the capability to edit the content tree 220 are generally referred to as “sysops,” although different levels of sysops are defined. Advantageously, different users can have different edit capabilities with respect to different nodes. For example, one user may have node edit privileges (or “sysop privileges”) only at a particular Dirsrv folder node (plus any children of the Dirsrv folder node), while another user may have node edit privileges only at a particular BBS folder node (plus any children of the BES folder node).

[0090] As a user moves from node to node of the content tree 220 using the Explorer, the Explorer requests the node-specific access rights of the user from the Directory Service. If these access rights indicate that the user has sysop privileges at a particular node, the Explorer advantageously displays a set of node edit menu items, allowing the user to remotely edit the properties of the node using the TreeEdit API. A preferred set of tools for remotely editing the content tree 220 is described in a concurrently filed, commonly assigned U.S. application having the title SYSTEM AND METHOD FOR EDITING CONTENT IN AN ON-LINE NETWORK, which is incorporated herein by reference.

[0091] As pictorially illustrated in FIG. 1, the Dirsrv directory structure 202 is stored on each of the application servers 120 of the Dirsrv service group 132. Similarly, the BBS directory structure 204 is stored on each of the application servers 120 of the BBS service group 134. Accordingly, any single application server 120 within the Dirsrv service group 132 can provide a directory of all of the nodes within the Dirsrv namespace 212, and any single application server 120 within the BBS service group 134 can provide a directory of all of the nodes within the BBS namespace 214. As with other service groups within the host data center 104, each service group 132, 134 may have as few as one application server 120.

[0092] As indicated above, the Directory Service Providers may store their respective nodes as node files, or may use an alternative database arrangement. In the preferred embodiment, each node includes a listing of the parents and children of the respective node, and thereby specifies the position of the node within the content tree 220. With reference to FIG. 2, each node also includes a variable-length list of node properties, as illustratively shown for node 4. These node properties essentially define the corresponding content object (or “service area”), and specify how the content object may be accessed.

[0093] The node properties stored by the Directory Service Providers vary according to node type. For example, some properties are applicable only to folder nodes, some are applicable only to leaf nodes, and some are applicable to both leaf and folder nodes. Further, some properties are service-specific, meaning that they apply only to a certain service. An example of a service-specific property is a Chat room “maximum occupancy” property, which specifies the maximum number of users that can concurrently participate in a corresponding Chat conference. Further, some properties can be viewed by regular users (i.e., non-sysops) via a properties dialog box of the Explorer, while other properties are hidden from regular users, and can be seen only by sysops and/or system administrators.

[0094] In accordance with the present invention, a set of generic (i.e., non-service-specific) properties is defined to allow Directory Service Providers to store certain types of information. The mnemonic names and descriptions of these generic properties are provided below. Provided in parenthesis following each name and description is a list of codes which identify certain characteristics of each generic property. These codes are defined in Table 1. 1

[0095] The generic properties are as follows:

[0096] Name. This is a human readable name, which can be displayed by a client (i.e., client application) of the Directory Service. For example, a folder node could have the name “Health & Fitness,” and could have children folder nodes with names of “Health & Fitness Chat” and “Health & Fitness BBS.” Every folder node and every leaf node has a name. For junction point nodes, the name of the target node is used (i.e., the property is stored remotely as a local property of the target node). In the preferred embodiment, the Explorer (which, as indicated above, is the primary client of the Directory Service) displays the name along with or in place of the corresponding icon. (V, F, L).

[0097] Directory Entry ID (DEID). This is a 64-bit number which uniquely identifies a node within its respective provider namespace. (A provider namespace can thus have up to 2⁶⁴ nodes.) Every node has a DEID. (NV, F, L).

[0098] Application ID (APPID). This is a 32-bit number that is required of every node. For leaf nodes, this number identifies the client application associated with the node, and is used by the Explorer to launch this client application when the user double-clicks on the node. (The client application then opens a pipe to the associated service.) For folder nodes, the APPID indicates the provider namespace (e.g., Dirsrv or BBS) in which the node resides. (The Directory Service can thus support up to 2³² different namespaces.) For junction point nodes, the APPID indicates the provider namespace in which the target node resides. (NV, F, L).

[0099] Service Group ID. (Also referred to as the data set ID, or “Dset”.) This is a 16-bit number which identifies the service group (132, 134, etc.) of the Directory Service Provider in which the node resides. Every node has a service group ID. Each Directory Service node is uniquely identified globally by the combination of the node's DEID, APPID and Service Group ID. (NV, F, L).

[0100] Icon ID. This is a 32-bit number (in the form of a “shabby ID,” as described below) which identifies the icon to be displayed by the Explorer (or other client) as a representation of the node. Icon bitmaps are stored by the Directory Service, and are sent over the network upon request by the Explorer. Multiple nodes may have the same icon. (NV, F, L).

[0101] Flags. This is an 8-bit value which indicates whether the node is a folder, leaf, or junction point. Every node has the Flags property. (NV, F, L).

[0102] Security Token. This is a 32-bit value which identifies a content category to which the node has been assigned for security (i.e., access rights) purposes. When a user attempts to view or access a node, the node's security token and the user's 32-bit account number are used to determine the user's access rights with respect to the node. Every folder node and every leaf node has a security token. For junction point nodes, the security token of the target node is used. (NV, F, L).

[0103] Description. This is a human-readable textual description of the service area corresponding to the node. The Directory Service places no limitation on the length of the description. (V, F, L).

[0104] GoWord. This is an optional property of nodes in provider namespaces that support GoWord searches. GoWords are in the form of character strings. If a Directory Service Provider supports GoWord searches, then the GetDeidFromGoword API (discussed below) can be used to retrieve the DEID of the node with a particular GoWord, and the node can then be directly accessed (assuming the user is authorized to access the node). Two nodes within the same provider namespace cannot have the same GoWord. (V, F, L).

[0105] Search Keywords. These are search words which may optionally be specified by sysops to permit keyword searching for nodes on particular topical areas. Multiple search keywords may be specified for a single node. The search keywords are cross-referenced to the corresponding node by a “find” service. (V, L, F).

[0106] Owner. This is a 32-bit vendor ID which identifies the entity which provides or derives revenue from the corresponding service. (V, F, L).

[0107] Sysops. These are the names of the users that are sysops of the node. (V, F, L).

[0108] Pricing. This is a 32-bit value which indicates the cost to the user, if any, associated with accessing the corresponding service area. For example, the pricing property of a node for a Chat room specify a cost to the user of $1.50 per use, or $2 per hour. The general format of the pricing property is described below. (V, F, L).

[0109] Rating. This is a 32-bit value which specifies a suggested appropriate audience for the content which corresponds to the node. Ratings include “GA: General Audiences,” “MA-13: Mature Audiences,” and “AO: Adults Only.” (V, F, L)

[0110] Run Info. This is a localized string containing miscellaneous run-time information needed (for certain nodes) to start or open a pipe to a service. For example, the property could contain a filename or other moniker that specifies a file on an application server 120. (NV, L).

[0111] Locales. This optional property is in the form of a string of locales identifiers (“LCIDs”) that identify the locales (i.e., languages and/or geographic regions) to which the node has been customized (or in which the node is viewable). For example, the locales property of a node that includes a textual description (or audio narration) that is in spanish may have only the LCID for “spanish” (which may be set by a sysop who creates the node); the locales property of a node for a rock music audio clip may include the LCIDs of many different languages and/or regions. In one embodiment, the locales property may be used to specify a geographic region to which the content object applies. Thus, for example, the locales property of a “classified ads” BBS node that is directed to residents of Daytona Beach Florida may have the LCID for Daytona Beach. As described below, the Directory Service provides a mechanism for allowing the client to specify the locales that the user is interested in, and for filtering out any nodes that are not in any of the user-specified locales. This advantageously prevents the unnecessary downloading and viewing of nodes in which the user has no interest. (V, F, L).

[0112] Junction. For junction point nodes, this is the DEID of the target node. (NV).

[0113] Parents. This is the number of parents of the node. The Directory Service determines this number on-the-fly (rather than storing the number) upon request from the client. (NV, F, L).

[0114] Children. This is the number of children of the node. The Directory Service determines this number on-the-fly (rather than storing the number) upon request from the client. (NV, F).

[0115] Access Rights. This is a sixteen bit value, retrieved by the Directory Service from an access rights database 152, which specifies the access rights of a particular user at the node. Each defined bit of this value serves as a privilege level flag for indicating whether or not the user has a particular privilege level at the node.

[0116] In the preferred embodiment, the user can have one or more of the following privilege levels: viewer, observer, user, host, sysop, sysop manager, supersysop. Although the access rights value is technically not a property of the node (since the value may vary from user to user), it is made available to the client by the Directory Service as a node property. (NV, F, L).

[0117] Soundfile ID. This is a 32-bit number (in the form of a shabby ID, as described below) which identifies a sound file that corresponds to the node. The various sound files are stored by the Directory Service separate from the node properties, and are provided to the client upon request. Each sound file specifies a corresponding sound or set of sounds that may be generated by the client microcomputer 102 when the user accesses the node. (NV, F).

[0118] Banner ID. This is a 32-bit number (in the form of a shabby ID, as described below) which identifies a banner object for providing a folder-specific banner within the right window pane 308 of the Explorer when the user opens a folder. Various graphics formats for specifying banners are supported, including bitmaps and various metafile formats. (A metafile is a standard Microsoft Windows graphics object that consists of lists of primitive graphics commands.) Banner objects are stored by the Directory Service separate from the node properties, and are provided to the client upon request. (NV, F).

[0119] Drfile ID. (Download-and-run file ID). This is a 32-bit number (in the form of a shabby ID, as described below) which identifies a download-and-run file for the node. In the preferred embodiment, download-and-run files are small files (usually less than 5 kilobytes) that sysops can place in their folders to provide information (such as information on the standards of on-line conduct) to users. The various download-and-run files are stored by the Directory Service separate from the node properties, and are provided to the client upon request. (NV, L).

[0120] Throughout this detailed description, the first letter of each of the above-listed mnemonic property names is capitalized to emphasize that these names correspond to defined properties. Further, acronyms (such as DEID, and APPID) of mnemonic property names will be fully capitalized.

[0121] In addition to the properties listed above, various other generic properties are possible. For example, generic properties may be included to specify the creation date of the node, the date/time of the last modification to the node, the time frame (e.g., 12th century) to which the content of the node relates, the version of the node, or the DEIDs of other nodes to which the present node is related.

[0122] As indicated by the foregoing, the only properties that are required of all nodes in the preferred embodiment are the DEID, APPID, Service Group ID and Flags properties. The Name and Security Token properties are required of all leaf and folder nodes, and the Junction property is required of all junction point nodes. The remaining properties are optional, meaning that they may or may not be specified (depending upon the particular service with which the node is associated). As described below, a set of node editors are provided to inform the Explorer, for each service, of the properties which may be entered by sysops for the nodes of that service. These node editors also allow nodes to have service-specific properties, such as the above-mentioned maximum occupancy property. Typically, the set of properties that may be specified for a given node type (such as Chat room leaf nodes, or BBS folder nodes) includes a subset of the above-listed generic properties, and may include one or more service-specific properties.

[0123] As will be recognized from the foregoing, each node is simply a list of properties stored by or otherwise available via the Directory Service. This list of properties describes the corresponding service area (or content object) on the network, and in the case of leaf nodes, provides the information needed to enter the service area. By way of example, the property list for a Chat room node (which is one type of leaf node) will typically include user-readable information about the Chat room, and will include the information needed by the Explorer to launch the Chat client application and add the user to the Chat room.

[0124] The Directory Service operates generally as follows. In response to requests from the client (which, in the preferred embodiment, is the Explorer), the Directory Service sends node properties over the WAN 106 to the client microcomputer 102, allowing the client to reconstruct user-selected portions of the content tree 220 (as shown in FIG. 3 for the Explorer) on the user's screen, and/or allowing the client to display node properties (such as the GoWord for the node) to the end user. To avoid unnecessary transfers of information over the WAN 106, the Directory Service advantageously returns only those properties that are specifically requested by the client.

[0125] Assuming that the Explorer is used as the client, when the user double clicks on a folder node (i.e., the icon for the folder node) from the right pane 304, or expands a node in the left pane 302, the Explorer uses a GetChildren API to generate a request to the Directory Service for the children of the folder node, specifying as parameters of the API the DEID of the folder node plus the names of the specific properties needed to display the children of the folder node. (The specific properties requested by the Explorer with such GetChildren calls are hard coded into the Explorer. In a preferred embodiment, the requested properties are the DEID, APPID, Name, Flags, Icon ID, Service Group ID, and the user's Access Rights.)

[0126] Various user actions cause the Explorer to generate requests for different node properties. For example, from the Explorer, a user can select a node and then select the “properties” command; this causes the Explorer to open the “properties” dialog box, which allows the user to select a “properties sheet” which lists the properties to be retrieved by the Explorer. The user may then specify, for example, “general” properties sheet which includes the “Rating” and “Pricing” properties of the node, causing the Explorer to generate a request for these properties. The TreeNav methods used by the Explorer for requesting properties and other information from the Directory Service are described below.

[0127] When the user double clicks on a leaf node from the Explorer, the Explorer initiates a service session with the corresponding service. To initiate the service session, the Explorer initially uses the APPID of the leaf node to identify the service application to be invoked. Once the identity of the appropriate executable file has been determined, the Explorer launches the client application for the service, and passes to the client application the DEID and the service group ID of the node. The client application then performs the appropriate service-related action. For example, if the node is a Chat room, the Chat client application uses the node's DEID to connect to the corresponding Chat room.

[0128] Before “showing” a node to the end user (by returning the requested properties of the node to the client), the Directory Service uses a GetAccountRights API to determine the access rights of the user with respect to the node to thereby determine whether the user is authorized to access the node. This access rights information is stored within the access rights database 152 on each security server 150. If the user is not authorized to access the node, the Directory Service does not return the properties of the node, and the node is not displayed to the user. By way of example, suppose that a user double clicks on the icon corresponding to node 1 in FIG. 2. This causes the Explorer to generate a GetChildren call to the Directory Service to obtain the children (i.e., enumerated properties of the children) of node 1. As parameters of the GetChildren request, the Explorer specifies the DEID of node 1, and specifies the properties (normally the Name, DEID, APPID, Service Group ID, Flags, Icon ID and Access Rights) to be returned for each child node. If, for example, the user is authorized to access node 4, but is not authorized to access node 5, the Directory Service will return only the properties of node 4. Thus, no properties of node 5 will be downloaded to the Explorer, and node 5 will not appear in the Explorer window on the user's screen.

[0129] To determine the user's access rights with respect to the node, the Directory Service initially reads the 32-bit Security Token associated with the node (which, as described above, is stored as a node property). The Directory Service then generates a GetAccountRights call, specifying as parameters of the call the node's Security Token and the user's 32-bit account number. The GetAccountRights API returns either a 16-bit access rights value which indicates the user's access rights with respect to the node, or else returns a code indicating that the user is not authorized to access the node. The GetAccountRights API includes code which generates queries to the access rights databases 152 to obtain user-specific access rights lists, and also includes code which implements an access rights cache for locally storing these user-specific lists. The GetAccountRights API is further described below.

[0130] With the exception of the Access Rights property, which is a special case, all of the above-listed generic properties are “local properties,” meaning that they are stored (or generated on-the-fly) locally (i.e., on the same application server 120) by the Directory Service Provider which stores the node. In accordance with one aspect of the present invention, a node may also have one or more “remote properties,” which are properties that are stored or generated by the service (such as Chat) with which the node is associated (as indicated by the node's APPID). When a remote property is requested by the client, the Directory Service Provider retrieves the remote property (via a remote procedure call, or “RPC”) from the associated service (which is normally implemented on a separate application server 120), and then returns the remote property to the client. To increase performance, the Directory Service also implements a remote properties cache (described below) for locally caching recently-retrieved remote properties. As described below under the heading “JUNCTION POINTS”, the Name and Security Token properties of a junction point node are always stored remotely by the Directory Service Provider that stores the corresponding target node.

[0131] The provision for the retrieval of remote properties advantageously allows certain types of information to be stored or generated by the end services (such as Chat or Mediaview), rather than by the Directory Service Providers. This is particularly useful for information that changes dynamically. One example of a node property which may advantageously be stored remotely is a “Current Occupants” property of a Chat room, which indicates the current number of participants in the corresponding Chat conference. Because the Current Occupants property changes frequently, it would be inefficient to store this property with the node; doing so would require frequent update transactions over the LAN 122.

[0132] In accordance with one aspect of the present invention, a mechanism is provided which allows Directory Service Providers to maintain respective databases of data entities that are shared by multiple nodes. These shared data entities are referred herein as shared blocks of bytes, or “shabbiest” In the presently preferred embodiment, four types of data entities are stored as shabbies: icon bitmaps, download-and-run files, sound files, and banner objects. As illustrated in FIG. 2 for one preferred embodiment, only the Dirsrv service implements a shabby database 222. Each shabby within the database 222 is specified by a unique 32-bit shabby ID (“SHID”).

[0133] The ability for a Directory Service Provider to maintain a database of shabbies separate from the nodes of the Directory Service Provider is provided through special TreeNav and TreeEdit methods that may be used to create, delete, modify and download shabbies, and by the provision of certain node properties (such as the “Icon ID” property) that allow specific shabbies to be referenced by nodes. Because shabbies are stored separately from the node properties, there is no need to store multiple copies of each shabby, even though multiple nodes may share the same shabby. By way of example, suppose that the same icon is used for all Chat rooms, and that 30 Chat room objects currently exist within the Dirsrv namespace 212. Rather than storing 30 copies of the bitmap for the Chat room icon, the Dirsrv service stores the bitmap as a shabby (within the Dirsrv shabby database 222), and stores the shabby ID of the bitmap as the Icon ID property each Chat room node. The preferred methods by which shabbies are stored by Directory Service Providers and downloaded to client computers 102 are described below under the heading “SHABBIES.”

[0134] 3. Client-Server Architecture of Directory Service (FIG. 4)

[0135] FIG. 4 illustrates the primary client and server software components which may be invoked when a user uses the Explorer client application 402 to explore and/or edit the content tree 220, and also illustrates the primary data entities accessed by these software components.

[0136] The client components include the Explorer client application 402, a variety of other client applications 404 (such as the client applications for the Chat, BBS and Mediaview services), the TreeNav API 412, the TreeEdit API 414 (which, as discussed below, may be omitted in embodiments which do not allow remote editing of the content tree 220), and network layers 416. The server components include network layers 418, the Dirsrv and BBS server applications 420, 422 (which are both Directory Service Providers, and which together form the Directory Service 424), and various other server applications 426 (such as the Chat and Mediaview service applications). The Directory Service 424 accesses the Dirsrv and BBS namespaces 212, 214, and may access additional provider namespaces 438 that correspond to other Directory Service Providers (represented by the ellipsis in FIG. 4).

[0137] The Explorer 402 includes multiple navigator modules 440 for navigating the content tree 220. Each navigator module 440 corresponds to and is used to navigate a respective provider namespace 212, 214, 438. Thus, for example, a