Field of the Invention The present invention relates to digital networks, and in particular, to methods and systems for efficient creation, management and configuration of group networks.

Background of the Invention Enterprises and individual users increasingly rely upon network architectures and application software to store, manage, retrieve and display an ever-increasing volume of different types of information (including documents, e-mails, digital photographs, faxes, and other files and data), as well as to access and interact with other types of resources, including printers, processing resources and other devices. Conventional network design has largely matured in the recent past, such that conventional network architecture is relatively standard across various environments and applications.

By way of example, FIG. 1 depicts a LAN/WAN environment typical of the prior art. As shown in FIG. 1, conventional computing devices 35000 and human users and/or applications programs (herein referred to as actors 30000) reside in one controlled physical location

where they are connected to network file servers 4000 under the supervision of human network administrators 3000.

In a typical, conventional network environment, each network must be created and initialized by an administrator 3000. In addition, all maintenance functions, including: adding and removing actors 30000; adding and removing file servers 4000; adding and removing and maintaining group privacy and rights, adding and removing remote actors 900 and computing devices 1000; and maintaining the firewall 2000 must be performed by the administrators 3000.

To share resources that reside on computing devices, actors must either explicitly place such resources on file servers or create special file sharing folders. In either case, the actors must ask for and receive support from administrators to create the appropriate rights groups so that in each case appropriate privacy of shared resources is maintained. Remote actors must install, manage, and activate a special Virtual Private Network application 800 (hereafter referred to as VPN) each time they wish to access the network. Once again, each remote actor must ask for and receive support from the network administrator to maintain firewall compatibility and access for each remote user.

Thus, while the structure shown in FIG. 1 is suitable for delivering a basic set of network services, such a configuration typically requires a controlled, defined environment in which to operate; additional hardware such as network servers, firewalls and VPN applications for operation, as

well as extensive and intensive investment in and support from network administrators.

This also requires additional effort and imposes additional overhead on remote actors every time they wish to access the network, a situation which becomes increasingly burdensome in a world of mobile workers.

It would therefore be desirable to provide improved network configurations, methods and systems, particularly adapted for enabling the configuring and management of groups and associated resources.

It would also be desirable to provide such networks that do not require, for their efficient operation, a controlled environment, additional hardware such as network servers, firewalls and VPN applications, or extensive investment in and support from network administrators.

It would also be desirable to provide such networks that do not impose additional overhead on remote users each time they wish to access the network.

It would further be desirable to provide such networks operable to deliver a varied set of network services such as distributed search and individual views, as well as the ability to back up and mirror data, and which are readily extensible both in the types of resources that are accessible and the types of services offered by the network.

Summary of the Invention The present invention provides improved network configurations, methods and systems, particularly adapted for the creation, configuration and management of collaborative groups.

In one aspect, the invention provides a group network for sharing resources characterized by: at least one computing device; zea set of resources (defined as but not limited to files, folders, e-mails, e-mail attachments, databases, object stores, computing devices, application processes); zea view element (defined as a user specified organization of resources that is independent of the physical storage organization of those resources); zea group element (defined as a group of users who have consented to share resources); an endpoint (defined as a specific network communications protocol); a ring server application used to maintain resources and provide network services associated with at least one actor (defined as a user); a network services manager that operates to determine which ring server; a ring server service that is required to access and service resources; an endpoint manager operable to manage communications to or from ring servers within the network services manager.

A further aspect of the invention comprises a namespace that can define a path to each resource, and that uniquely identifies and provides access to

resources and services in the network regardless of the physical network location of the resource or whether physical locations change, so that an extensible group resource manager, including resource providers, are operable to interact with the namespace. This enables the invention to: authenticate requests for resources contained within a group element; . provide access to resources contained in a group element ; . address resources contained within a group element ; share resources within a group element; . provide notification of events that occur within a group element; allow actors to publish new resources to a group element ; perform edit operations on resources within a group element; search for resources the contain information matching query criteria within a group element; and . harvest new resources that contain information matching query criteria within a group element.

Other aspects of the invention will be described in greater detail below.

Brief Description of the Drawing Figures FIG. 1 is a schematic diagram showing the overall structure of a conventional, prior art network.

FIG. 2 is an overall schematic of the major components of one embodiment the invention.

FIG. 3 is a screen shot example of a user publishing a document to a network group in accordance with the present invention.

FIG. 4 is a diagram depicting architectural components of the embodiment of FIG 2.

FIG. 5 is a diagram depicting a group namespace used by the group resource manager of FIG. 4.

FIG. 6 is a flow chart illustrating the method of resolving a resource path within the group namespace of FIG. 5.

FIG. 7 is a flowchart depicting detail of the method of resource resolution within the group namespace of FIG. 6.

FIG. 8 is a diagram that illustrates the architectural components and key entities of distributed search and how they interact.

FIG. 9 is a flow chart illustrating a method for distributed search across peer devices in a group network in accordance with the present invention.

FIG. 10 is a flow chart illustrating a method for dynamic view implementation in accordance with the present invention.

Detailed Description Of The Invention The detailed description of the invention is divided into five major sections; Section 1: Overview, Section 2: Group Network, Section 3: Distributed Search, and Section 4: View Harvesting.

1. Overview FIG. 2 shows a high level view of the major components of a software embodiment of the present invention that includes the users, computing devices and information with which that software embodiment interacts. The following subsections of the overview describe the each of the major components.

1.1. Actors Actors 30000, represents a human or an autonomous application. For example, there may be five actors which comprise the Management Group 40000: President, Vice President, Secretary, and Treasurer, and a document server that contains a repository of company documents.

Actors issue commands and act on resources 50000. Actors also have both a common name and a uniquely identifier called an actor ID (usually an e-mail address such as actor@company. com). Actors are created when a ring server application 20000 is installed on a computing device 35000. A ring server application may have multiple actors (who typically use their e-mail addresses as their identifiers, for example actorl@company. com, actor2@company. com) installed using different actor IDs. An actor may also have multiple computing devices each with a unique identifier (referred to herein as a GUID).

Once installed, actors may participate in groups (for example Management, East Coast, My Family). In one practice of the invention,

actors are capable of creating, modifying, deleting, and publishing resources into groups.

By way of example in FIG. 3, an actor is shown publishing a document to a group. Actors are authenticated upon joining and accessing a group. Only invited actors may join a group. An actor is assigned a role when joining a group that determines the actor's access rights to resources within the group. Additionally, an actor must provide a group key to access any resource with the group.

1.2. Groups Referring once again to FIG. 2, enumerated below are the properties of a group 40000. In accordance with one practice of the invention, a group provides a security mechanism to limit access to authenticated actors 30000 who are members of a given group. Groups establish roles used to define access rights to resources within a group. Groups have names used navigate and access objects within a Group Network. In addition, a group contains a collection of one or more actors who are members of the group. There may be one or more groups within the group network 5000. Groups have a name (for example management) and unique group ID that is used to identify the group. Groups can also have both a common name and a group ID, an internal code which is used to uniquely identify the group. There may be multiple groups using the same common name.

The group ID is automatically generated and assigned to a group when it is created and is never reused for another group. Groups are created by actors and persist until they are removed by an actor with Modify Access rights. Once removed, the group ID may never be used again, although the group name may be used for other groups. Groups may

be created, renamed, or removed. Actors within a group may discover other actors within the group to which they belong, as well as access resources published into that group.

Only group members may access the group. Each group is assigned a key which is required by its actors to access resources within the group.

For example, a company may have established three groups used to share company resources; a Management Group, an Accounting Group, and a Legal Group. Only actors with valid keys may access the resources published to the group.

1.3. Resources Referring once again to FIG. 2, resources 50000 are objects that may be added to or shared with one or more groups 40000. Resources may be folders and files on a computing device 35000 or other device, information stores such as e-mail repositories and databases, and electronic devices such as a printer. Resources contain information or provide a service that is desired by actors 30000 within a group into which it is published. Access to resources is managed by a single ring server application 20000. One or more resources reside in a view 60000. A resource may be linked to another resource. A resource may be the source of one or more links. A linked resource has exactly one source resource. Access to a resource is controlled by one or more view access rights. All resources share a common set of traits and methods that are exposed by implementing the resource object Application Programming Interface (API). All resources have a common name used to identify them with in the Group Network namespace. A resource's capabilities are defined by the resource object

API. Access to resources is enforced by group access rights assigned to an actor through a view role.

Resources within the group network are addressed using a resource path. A resource path is a hierarchically ordered set of one or more identifiers to objects within the group network namespace and is discussed in greater detail below.

1.4. Group Network Namespace Referring once again to FIG. 2, a Group Network 5000 is a service used by ring server applications 20000 to communicate with other ring server applications. The group network namespace provides a way to identify groups 40000, actors 30000, ring server applications, views 60000, and resources 50000.

1.5. Views Referring once again to FIG. 2, a view 60000 is a collection of resources 50000 that have been created or published by an actor 30000 on a ring server application 20000 within a group 40000. A view comprises a grouping and organizing mechanism to share resources with other actors within a given group. Access to views is enforced through one or more view access rights.

Views may contain other views in a hierarchical structure. There is a default view which is automatically created for an actor upon joining a group. Views have names that are part of the group network 5000 namespace used to navigate and access group resources within a view.

Views are created by an actor and remain until removed by the actor that created them.

Views have a common name that used by ring server applications to address and access the view. A view may be the target of an enumerated copy, move, delete, rename, or publish operation. Views may contain resources or other views. Views enforce access rights that determine access to the resources and other views within a given view. An actor is assigned a role that provides a bundle of access rights to views.

1.6. Ring Server Application Referring once again to FIG. 2, a ring server application 20000 is an instance of the networked software application that manages access to resources 50000 within its domain by actors 30000 installed on the ring server application, or by actors installed on remote ring server applications.

Ring server applications provide services to enable secure access to local and remote resources by authenticated actors and other ring server applications addressable within the group network. Ring server applications have both a common name and a GUID.

A ring server application is created when it is installed on a computing device 35000. It exists until it is uninstalled from the computing device. Ring server applications provide the services actors use to access and operate on a group's resources both locally and remotely. For example, ring server applications provide services which enable actors to read, write, create, delete, copy, move, publish, and search resources within groups 40000.

1.7 Ring Server Application Services and Rings FIG. 4 is a block diagram top level view of the ring server application 20000 services and group 40000 services.

1.7. 1 Network Services Manager Service Group As shown in FIG. 4, the network services manager 22000 service group consists of an endpoint manager 22300 and various rings 22200 and 22100. The network services manager is responsible for determining which rings are required for a particular installation, loading and initializing all required rings, and unloading all rings in the proper order. The endpoint manager determines which endpoints are required for a particular installation, loads and initializes all required endpoints, manages incoming and outgoing communications threads, directs outgoing data streams to a specific endpoint, directs incoming data streams to a specific ring in the network services layer, and unloads all endpoints in the proper order during system shutdown.

1.7. 2 Endpoints Referring again to FIG. 4, each endpoint 22310,22320, and 22330 is a dynamically loadable software component that is responsible for transmitting and receiving data over a specific communications transport and protocol. The HyperText Transmission Protocol (HTTP) endpoints 22310 and 22320 implement the HTTP and HyperText Transmission Protocol Secure (HTTPS) protocols. There are two instantiations of the HTTP endpoint in a typical installation. The HTTP Endpoint General endpoint manages general HTTP traffic. The HTTP Endpoint Event endpoint is used by the GNET event service 22260 to publish distributed events. The Message Application Programming Interface (MAPI) endpoint 22330 interfaces to MAPI enabled e-mail clients in order to send and receive e-mail traffic.

1.7. 3 Rings Continuing with FIG. 4, each ring 22100 and 22200 is a dynamically loadable network application that is comprised of a collection of one or more network services. The endpoint manager 22300 directs incoming data streams to a ring. The ring optionally converts the incoming stream to the internal ring protocol and directs the traffic to the appropriate service for further processing. For outgoing traffic, a ring optionally converts from the internal ring protocol to an endpoint data stream and uses the endpoint manager to send that stream. A ring is responsible for determining which services are required for a particular installation including: loading and initializing all required services; . registering the ring namespace with each endpoint as specified in the installation configuration; accepting endpoint incoming data streams; . optionally converting to the internal ring protocol and direct the incoming data stream to the appropriate service; accepting outgoing traffic from a ring service, and . optionally translating from the internal ring protocol before sending to the appropriate endpoint.

1.7. 3.1 GNET Ring Referring to FIG. 4, the GNET ring 22200 implements the GNET group network protocol. Ring server application (20000, FIG. 2) IDs are used as GNET addresses. The GNET sender uses the finder service 22210 to determine the best endpoint for reaching a specific ring server

application and maps the ring server application ID to an endpoint specific address. If the ring server application can not be reached directly, the rendezvous service 22250 is used to reach the ring server.

1.7. 3.1. 1 Finder Service Referring to FIG. 4, the finder service 22210, located in the GNET ring 22200, maintains a distributed database of information about the primary abstractions in the system such as ring server applications (20000, FIG. 2), actors (30000, FIG. 2), and groups (40000, FIG. 2). These are known as advertisements. Each ring server application maintains a local copy of the advertisements of interest to that ring server application.

Advertisements of interest are defined as the following: e the server advertisement for the local ring server application; actor advertisements for all actors installed on the local ring server application; . group advertisements for each group of which a local actor is a member (these are referred to as"known groups"); . actor advertisements for each actor in known groups (these are referred to as"known actors"), and; server advertisements for all ring server applications that local and known actors are installed on.

The finder service uses the event service 22260 to synchronize local advertisements with the master finder advertisement database. The finder service uses the master finder to publish changes to locally editable advertisements and to discover new advertisements of interest.

1.7. 3.1. 2 Remote Group Service Referring to FIG. 4, the remote group service 22230, located in the GNET ring 22200, implements remote access to the extensible group resource manager.

The remote group service has the following responsibilities: authenticate and process incoming GNET group resource requests; formulate and transmit outgoing GNET group resource requests; and use encrypted pipes to process incoming and outgoing GNET group resource requests.

The remote group service 22230, located in the GNET ring 22200, also supports indirect communication for servers that can not directly communicate because of firewalls or other network roadblocks. A ring server application 20000 can optionally subscribe to rendezvous events from a rendezvous server (12000, FIG. 2) that is openly addressable on the Internet. The ring server application's advertisement specifies which rendezvous server, if any, is used by that ring server application. The rendezvous server uses the event service 22260 to notify the destination ring server application that GNET packets are available. The destination ring server application then polls the rendezvous server for those packets.

The rendezvous service 22250 has the following responsibilities: encapsulate outgoing GNET requests into outgoing GNET rendezvous requests and send them to the rendezvous service on the designated rendezvous server;

. extract incoming GNET responses from incoming GNET rendezvous requests and forward the response to the original requesting service; . extract incoming GNET requests from incoming GNET rendezvous requests and forward the request to the appropriate service; . encapsulate outgoing GNET responses into outgoing GNET rendezvous requests; . forward the response to the rendezvous service on the designated rendezvous server; store incoming GNET rendezvous requests destined for other servers; and . notify other ring server applications using the event service of stored GNET rendezvous requests.

1.7. 3.1. 3 Pipe Service Referring again to FIG. 4, the pipe service 22220 is a GNET packet distribution service that supports the following: optional encryption of the GNET packets, optional compression of the GNET packets, optional fragmentation of large GNET packets, one to one distribution, one to many distribution, many to one distribution, and many to many distribution.

1.7. 3.1. 4 Remote Search Service Referring to FIG. 4, the remote group service 22240 is located in the GNET ring and implements remote access to the core search manager. The remote search service has the following responsibilities: authenticate and process incoming GNET search requests; authenticate and process incoming GNET search requests; and

formulate and transmit outgoing GNET search requests, process incoming GNET search responses.

1.7. 3.1. 5 Event Service Referring to FIG. 4, the event service 22260 is located in the GNET ring and implements the distributed event notification mechanism. The event service has the following responsibilities: allow services to publish and subscribe to local and remote events; subscribe to events on remote ring server applications 20000; distribute those events locally, and distribute local events to remote subscribers.

1.7. 3.2. KNOWMO Ring Referring again to FIG. 4, the KNOWMO ring 22100 is used by the instant network user interface and by desktop applications to access group resources (50000, FIG. 2). The KNOWMO ring is responsible for the following: authenticating the actor (30000, FIG. 2) and establishing session credentials, and associating incoming requests with a session.

1.7. 3.2. 1 WebDAV Service Referring to FIG. 4, the World Wide Web Distributed Authoring and Versioning (WebDAV) service 22110 implements and extends the Request for Comment (RFC) 2518"HTTP Extensions for Distributed Authoring- WebDAV"standard. WebDAV requests for group resources (50000, FIG.

2) are delegated to the extensible group resource manager.

1.7. 3.2. 2 HTML Service The Hypertext Markup Language (HTML) Service 22120 returns static HTML pages used by the instant network user interface.

1.7. 4 Core Services Group Referring again to FIG. 4, the core services 21000 service group contains all the services necessary support the major feature components of ring server application 20000. Discussed below are the various services within the core services group.

1.7. 4.1 Actor Manager Service The actor manager 21200 maintains actor objects representing an actor in the system. The actor manager 21200 is responsible for the following: authentication of the actor (30000 FIG. 2); secure storage of group credentials and roles; synchronization with the finder actor advertisement; and editing of actor specific properties (for example, actor name) 1.7. 4.2 Group Manager Service Referring again to FIG. 4, the group manager 21230 maintains group objects in the system. The group manager is responsible for the following:

encapsulation of membership listing and editing; e specification of group roles; synchronization with the finder (see 11000, FIG. 2) group advertisement; and editing of group specific properties (for example, friendly name).

1.7. 4.3 Search Manager Service Referring to FIG. 4, the search manager 21240 orchestrates distributed searches. The search manager is responsible for the following: distributing remote search requests through the GNET remote search service; . coalescing search results for the search result provider 21140; executing local searches; and . responding to remote search requests from the GNET remote search service 22240.

1.7. 4.4 Session Manager Service Referring again to FIG. 4, the session manager 21250 maintains session state for authenticated actors (30000, FIG. 2). The session manager is responsible for the following: runtime storage of actor group credentials and roles; and session expiration and re-authentication.

1.7. 4.5 Extensible Group Resource Manager Service Referring again to FIG. 4, the extensible group resource manager 21100 maintains resource provider objects and maps resource paths (see discussion below) to a specific resource provider.

The group resource manager 21100 is responsible for the following: enforcing group visibility constraints based on session group credentials and roles; mapping a resource path to a resource provider; and loading and initializing all required resource providers.

In turn, each resource provider is responsible for the following: enforcing access constraints based on session group credentials and roles; enforcing resource capability constraints for the requested resource; and accessing and manipulating the requested resource.

Resource providers maintain an extensible architecture and new providers can be written for almost any type of system resource. The following paragraphs describe various software embodiments of resource providers.

1.7. 4.5. 1 Local File System Provider The local file system provider 21110 of FIG. 4 provides access the local file system. Authenticated local actors (30000, FIG. 2) have direct

access. Remote group members may have indirect access to files explicitly published to a group (40000, FIG. 2) by an authenticated local actor.

1.7. 4.5. 2 Group File System Provider The group file system provider 21120 of FIG. 4 allows access to resources (50000, FIG. 2) published to a group (40000, FIG. 2).

Authenticated group members have direct access.

1.7. 4.5. 3 MAPI Provider The MAPI provider 21130 of FIG. 4 allows access to the MAPI compliant e-mail store for a local actor. Authenticated local actors (30000, FIG. 2) have direct access to their own MAPI store. Remote group (40000, FIG. 2) members may have indirect access to files explicitly published to a group by the authenticated local actor.

1.7. 4.5. 4 Search Result Provider The search result provider 21140 of FIG. 4 allows access to a local actor's (30000, FIG. 2) search results. Authenticated local actors have direct access to their own search result store. Remote group members may have indirect access to results explicitly published to a group by the authenticated local actor.

1.7. 4.5. 5 Remote Group Provider The remote group provider 21150 of FIG. 4 uses the GNET remote group service 22230 to allow a local authenticated group member to access group resources (50000, FIG. 2) on a remote ring server application (20000, FIG. 2).

1.7. 4.5. 6. Link Provider The link provider 21160 of FIG. 4 resolves links to local and remote resources (50000, FIG. 2).

2. Group Network In accordance with the practice of the invention, the group network is one software embodiment of the group namespace used by the extensible group resource manager (21100, FIG. 4) to identify all resources (50000, FIG. 2) on the group network (12000, FIG. 2) and by each ring server application (20000, FIG. 2) to manage all resources on the group.

2.1 Resource Paths Each resource (50000, FIG. 2) is uniquely identified by a resource path (as shown in FIG. 5). A resource path is an ordered collection of elements with each element separated by the Resource Path Separator Character'/'. Each element may optionally include a provider switch which has the form" {provider name}"where provider name identifies a resource provider such as the providers shown in FIG. 4.

FIG. 5 is an illustration of how a resource path is obtained. The first element in the group namespace is the group file system provider (21110, FIG. 4), also known as the GFS root provider as shown in FIG. 5. The GFS root provider contains group resources.

Referring to FIG. 5, which depicts a GFS root provider 72000 with two groups,"Group A"73100 and"Group B"73200. Each group contains actors. "Group B"73200 contains two actors, "Actor 1"74100 and"Actor 2"74200.

Each actor contains ring server applications. "Actor 2"74200<BR> contains two ring server applications, "Local Ring Server Application A" 75100 and"Remote Ring Server Application B"75200.

Each ring server application contains resources (50000, FIG. 2). <BR> <BR> <P>"Local Ring Server Application A"75100 contains two views, "View A" 76100 and a link to a view"View B"76200.

The view"View A"76100 contains two resources, the resource "Resource 1"77100 and a link to the resource"Resource 2"77200. The resource path to"Resource 1"is shown in FIG. 5 as item 78300. The resource path to"Resource 2"is shown in FIG. 5 as item 78200. Note that because"Resource 2"is a link the resource path depicted contains a provider switch to the link provider.

Referring now to FIG. 5, "Local Ring Server Application B"75200 contains two resources, the views"View C"76300, and"View D"76400.

The resource path to"View C"76300 is shown in FIG. 5 as 78100. Note that because the view"View C"76300 is on a remote ring server application, the resource path 78100 depicted contains a provider switch to the remote group provider. The remote group provider is responsible for accessing the resource on the remote ring server application.

2.2 Group Namespace Resolution FIG. 6 shows the group namespace resolution process. The group namespace resolution process is used to identify the resource provider that owns the resource and to construct the resource object used to access the resource (50000, FIG. 2).

As shown in FIG. 6, the first step is to create a resource path object 80200. The resource path object contains the resource path (as previously

explained) parsed into elements. The first element is examined 80300. If the element contains a provider switch, the specified provider 80400 is used to resolve any remaining elements in the resource path, otherwise the default provider 80500 is used resolve any remaining elements in the resource path. The provider processes 80600 any remaining elements in the resource path until there are no more elements or until another provider switch is detected. The provider marks the resource path with the information it needs to identify its portion of the resource path. This is referred to as a resource path root. The provider also advances the index used to identify the current element being resolved in the resource path past the elements resolved by this provider. If there are remaining elements 80850, the next specified provider is used to repeat the process 80400 until there are no more elements to be resolved. Once all elements have been resolved 80800, the last provider is used to construct the resource object used to access the resource.

2.3. Group File System Root Provider FIG. 7 shows the group namespace resolution process for the GFS root provider (as show in FIG. 5) in greater detail. FIG. 7 shows a GFS root provider (72000, FIG. 5) that uses the local file system provider (as shown in FIG. 4) to store group (40000, FIG. 2) resources. Other resource providers can be used in place of the local file system provider.

In FIG. 7, the GFS root provider (72000, FIG. 5) first sets the GFS root 90200 as the root of the element being processed in the resource path.

The GFS root is the location in the local file system that the GFS root provider uses to store groups. If no elements remain in the resource path,

then the resource is the GFS root and 90400 the GFS root provider is used to construct the resource object.

If there are remaining elements in the resource path, then the next element must identify a group. The index to the current element in the resource path is advanced 90500 to the next element.

If no elements remain the resource path, then the resource identified is a group and the group root provider 90700 is used to construct the resource object. If there are remaining elements in the resource path, then the next element must be an actor. The index to the current element in the resource path is advanced to the next element 90800. If no elements remain in the resource path, then the resource identified is an actor and the actor root provider 92000 is used to construct the resource object.

If there are remaining elements in the resource path 90900, then the next element must identify a ring server application. The index to the current element in the resource path is advanced to the next element 92100.

If no elements remain in the resource path, then the resource identified is a ring server application and the ring server application root provider 92300 is used to construct the resource object.

If the ring server application is remote 92400, then the remote group provider is used to construct the resource object. If the ring server application is local, then the ring server application root 92600 is set as the root of the element being processed in the resource path. The ring server application root 92600 is the location in the local file system that the GFS root provider uses to store local group resources.

3. Distributed Search Distributed search is the process for performing a search across multiple peer devices on any network (for example TCP/IP). The following discussion describes the major concepts of distributed search as an introduction to the distributed search process itself.

3.1 Distributed Search Overview Referring now to FIG. 8, a search request 21241 is comprised of a scope 21242, a query 21243, and a response 21244. In general, actors build a search request by specifying a textual query expression and selecting a scope to direct or constrain the query. Once the request is built, it can be executed and returns a response containing the collection of resources 5000 satisfying the request query within the requested scope. Actors may build and execute multiple search requests simultaneously. Requests remain active until the actor cancels the request, or the request completes naturally.

Executing a search request is a distributed process whereby each ring server application 20000 within the search request scope is passed a copy of the request that is processed by their ring server application. The request may span one or more ring server applications in the group network as each application propagates a request to other applications that may have resources satisfying the request. Upon receiving a request from another peer, the request is executed against the local catalog 21245 used by the ring server application to locate responses to the search. As responses are found, they are sent back to the originator of the search request.

A search request object 21246 implements a search request 21241.

The search request object is a composite object that manages components of a search and presents an API to build, control, execute, and access the

results of the search. Each search request includes a search request resource path (see FIG. 5) used to identify the search. The path contains the location and name of the search request used to fetch results once the search completes, as well as the provider ID of the search request object used to process the search.

Each search request contains a search request ID that uniquely identifies this search to peers within the scope 21242 of the search. This identifier is important to delegated peers who may encounter a search request multiple times as the search request is propagated to peers within the scope. Secondly, the search request ID is used to collect search responses from delegated peers into the original search request.

Each search request also contains a search request name that is assigned by actors. Search request names are used to save, and later recall a search for execution. Each search request is owned by a peer, and as such, contains the owner's peer ID. Delegated peer ring server applications process search requests use the search request object ID to address response messages sent back to the search's originator.

The search request query 21243 is a text expression specifying the word or phrase and control words that specify the criteria used to find matching documents within a given scope. Most of the time, actors will enter simple expressions consisting of a set of words or a phrase. Other times, the advanced search request user interface will present helpers that allow the actor to construct complex queries. The syntax of the query expression will follow the Extended Backus-Naur Form (EBNF) notation.

EBNF provides a way to express complex queries, and is used by searching index services such as Microsoft's index service.

Searches are constrained by a search scope 21242. The search request scope is one or more resource paths that specify a set of groups, actors, and views, that determine the domain of the search or what is called the logical scope of the request. A search request will examine all resources within the search scope including linked resources. This may result in propagating the request to other peers who are sourcing the linked resources. A search request object 21246 can be serialized into an XML formatted text stream, called a search request message 21249. All information required to reconstruct the search request object is embodied in the search request message. A search request message is used to maintain the request between sessions, and to route the request to other peers for processing.

A search request response 21244 contains the results of a search request. The search request response is a collection of resource paths (see FIG. 5) to resources that satisfy the search request query 21243 including those from delegated search responses. The number of resources 5000 in the search request response may increase over time as responses arrive from delegated peers.

A search request execution context 21248 is a list of peer ring server applications 20000 that processed the request. Each time a request is delegated, the context is appended with the peer's ID. The search request execution context is sent back to the search request owner along with the response. Once the search request is built, the request is executed to obtain the results.

Referring to FIG. 8, a core service called the search manager 21240 is responsible for executing a search request for a given peer. The search manager is passed a search request object 21246, or a search request

message 21249 used to construct a search request object, that completely describes the search as was discussed in previous sections.

The search manager 21240 uses the search request object to enumerate the search request resource paths and delegate them to child search request's to be dispatched to a peer for processing.

The child search requests may refer to peers installed in the local ring server application, or peers installed on remote ring server applications. Once the child search requests are built, they are dispatched to either the local ring server application, or remote ring server applications based on the target of the search.

Referring again to FIG. 8, a remote search request is dispatched to the peer's remote ring server application via the remote search service 22240. The service serializes the request into a search request message 21249 and sends the message to the peer via the remote group service 22230. The remote search service 22240 on the destination peer's ring server application 20000 will handle the request by restoring the request into a search request and dispatching it to the search manager for processing. A record of the recently processed search requests is maintained to detect a search from being processed multiple times by the same peer. Note that both the search request ID and the search request message uniquely identify a search request since a peer may delegate a search with a narrower scope than the original request that needs to be treated separately.

Referring again to FIG. 8, the results of the search request will be returned to the originating ring server application 20000 via a search request message handled by the remote group server and remote search service 22240. Upon receiving the message, the originating search manager

21240 will add the peer's responses to original search request response collection.

Referring to FIG. 8, each ring server application 20000 relies on an index service 21247 used to by the search manager 21240 to process queries for resources on the local machine. The index service can be provided by a number of third parties who specialize in indexing various forms of resources. A custom search provider must be built for each index service in use by the search manager. Each search provider implements a search request API that allows the search manager 21240 to interact with the index service to process the search. This concludes the discussion of distributed search key concepts. The next several paragraphs describe the distributed search process itself.

FIG. 9 illustrates a method for distributed search across peer devices on a network; one or more group views can be searched for resources that meet the criteria of a search. To search the group network, an actor builds a search request 10150 that specifies a query, scope, and search request path.

The search request path is a resource path used to identify the search request and its provider ID is used to execute the search as well as a container to place the search results that can queried by the actor after the search completes. A query can be a text string, or other object, that contains search criteria used by the search provider to interrogate the index service to find resources that match the criteria. A scope is one or more resource paths that constrain the search to a set of groups, actors, or views. Each resource path in the scope can refer to a node in the group hierarchical namespace where all nodes below the selected node are used in the search.

Referring again to FIG. 9, once the search request is configured, it is submitted to the actor's ring server application 10160. There are several

interfaces that can be used to submit commands to the ring server application, including issuing HTTP requests to a port monitored by the KNOWMO ring's WebDAV Service as shown in FIG. 4. In FIG. 4 the KNOWMO ring service 22100 confirms the actor's identity by examining the actor's credentials passed in with the request. Once the request has been validated, it is passed to WebDAV service 22110.

As shown in FIG. 4, the WebDAV service 21110 is responsible for handling XML formatted requests from actors that subscribe to the WebDAV standard. In special cases, including search requests, this standard has been extended to handle requests that are not addressed in the standard. The WebDAV service's search request handler will process the incoming request by obtaining a search request object from the information passed to it in the message, and invoke the"execute"method to start the search.

Referring back to FIG. 9, in order to initiate the search process, a search request object is created 10180. The search request object implements the resource object interface that provides methods used to initiate and control the search. Once the object is created, the caller can set the query, scope, and other parameters before issuing the execute method to start the search. The search request object is obtained from the search manager by passing it the search request resource path. The search manager will examine the resource path looking for a provider ID. The provider ID is used to load a registered search provider responsible for creating the search resource object. Once the search request object has been created, the execute local search 10190 method is initiated to start the search.

Referring to FIG. 9, once the search is started, the first step is to locate any linked resources 10200 within the search scope. For each linked resource, the link's source resource path is added to the search scope. Once the search scope has been expanded for linked resources, the search scopes are sorted by peer within the group. For each group/peer combination, a child search request object is created and added to a collection of child search requests managed by the parent object 10200.

Once the search request has been separated into child requests by group/peer, they are executed as separate distinct search requests. This process is performed by iterating across the collection 10210 and delegating remote child requests to the remote peer ring server application, or executing local searches 10220 on the host ring server application. If the child search request is local, its execute method is invoked to start the search, otherwise remote request is dispatched to the remote search service for execution.

If the search scope uses a local resource path 10230, it is converted to a format used by the index service and added to the query context, and the search query is issued against the index service catalog 10240 to find results that match the given criteria within the given scope. For each result from the search, the result path is converted to be relative to the original scope resource paths, and the result is added to the search request result collection 10250. The path conversion process allows the results to be presented within the namespace and scope of the group network.

If it is not a local search 10220, for each remote resource path, any child search request object that refers to a remote peer is dispatched to that peer's ring server application for processing 10260. The remote search service is responsible communicating search requests and their results to

and from remote peers. Peer to peer communication is done through messages, so the search request object is serialized 10270 into a message format so it can be routed to the destination ring server application. The remote search service invokes the remote group service 10280 to route the serialized search request message 10290 to the appropriate remote peer ring server application. The remote group service on the destination ring server application fields the search request 10300 by dispatching the request to the remote search service.

The remote search request dispatches outgoing and incoming search requests 10310 from ring server application peers in the group network. For incoming search requests that have been delegated to the peer, it will un- marshal the request from the message by creating a search request based search request resource path and load it form its serialized message stream.

Once the search request objects have been created and loaded, the execute method is invoked to perform the search. For outgoing requests the system behaves similarly.

Once the search message has been received by the remote search service on the delegated peer's ring server application, a new search request object is created 10320 by invoking its load method. This will recreate the search request in the state it existed on the search request owner's ring server application.

Once the search request has created and loaded, it's executed by calling the execute 10330 method. The steps required to perform the search have already been described above, however there is an additional step which needs to be performed. Due to the distributed nature of the group searching process, it is possible that a peer ring server application may be delegated a search request that has been spawned from the same

owner multiple times. This causes a circularity to occur. To prevent this from propagating, the execute 10330 step compares the search request identifier to other search requests that have been executed recently. If it is found to match one of the recent searches 10330A, the search request is aborted 10330B and status is returned to the search process to continue with the next search request.

In FIG. 9, once the search completes, the results are sent to the owner 10340 of the original search results. The remote search manager is responsible for sending the results to owner. The results are serialized into a message to be sent via the remote group service. The owning peer ring server application's identifier used to address a group message is included in all delegated search requests.

Results from a delegated search request 10210 are initially handled by the remote group service which inspects the message and dispatches it to the remote search service. The remote search service locates the search request that owns the results and adds the results into the search request 10350. Once results from the search request are obtained, the actor is notified that the results may be retrieved and is passed the resource path which is used to fetch the results 10360. The search is then submitted to get results 10370 where based on where the resource path to the ring server application the search results are returned. The request to retrieve the search results is initially handled by the WebDAV Service in the KNOWMO ring. After examining the request, it is dispatched to the search manager. The search manager locates the referenced search request and builds a search object 10390 containing the current search results. The response is built by iterating over all the child search requests 10400. Once all the child search requests are processed, the result response is returned to

the caller. For each child search request, the results are added to the response 10420 until the children are all processed and the operation is complete 10410.

4. View Harvesting Referring now to FIG. 10, a dynamic view 11000 is a special instance of a view which is associated with a search request 21241 such that when the dynamic view is opened, the search request is executed and the contents of the response are commingled with the static contents of the view. In this fashion, actors can construct views which are dynamic in nature; that is, the content of the view changes as resources 50000 are added and removed from the scope 21242 of the underlying search request; those documents which match the query 21243 criteria automatically become included in the dynamic view, while resources which do not match the query criteria are automatically excluded.

Dynamic views are implemented by a dynamic view provider 11100, which exposes methods for creating and manipulating dynamic view resource objects 11200. The dynamic view resource object implements the resource object interface that provides methods for creating, opening, and manipulating the dynamic view.

The dynamic view resource object maintains properties which store parameters required to initialize a search request, such as query and scope.

When an attempt is made to enumerate the contents of the dynamic view resource object, a search request object is created, initialized with the search parameters (e. g. query, scope), and executed. Results from the search request are then presented as members of the dynamic view.

While various examples of the invention have been described above in connection with the attached drawing figures, those skilled in the art will appreciate that many variations and modifications are possible, and are within the spirit and principles of the invention, the scope of which is limited solely by the following claims.