WO2001037142A1

WO2001037142A1 - System and method for in context communications among overlapping communities of computer network users

Info

Publication number: WO2001037142A1
Application number: PCT/US2000/031758
Authority: WO
Inventors: Claus Spacil; Christian Wiener; Peter Harold Charles Madams; Pavel Shabalin
Original assignee: Zadu, Inc.
Priority date: 1999-11-17
Filing date: 2000-11-17
Publication date: 2001-05-25
Also published as: AU1660701A

Abstract

A communication system operative in a computer network together with an information retrieval system that retrieves information over the network and in which information to be retrieved is associated with network names that can be resolved into network addresses used to locate information to be retrieved on the network, the communication system comprising: a plurality of respective community servers resident in computer storage media accessible over the network, the respective community servers providing communication over the network among respective computers that use such respective community servers; a network name association structure resident in computer storage media accessible over the network, the network name association structure associating respective network names with respective community communication processes; and t least one instance of a network name receiving structure resident in computer storage media of at least one given computer accessible over the network, the network name receiving process receiving respective network names associated with information to be retrieved by the given computer in the network and informing the network name association structure of respective received network names.

Description

SYSTEM AND METHOD FOR IN CONTEXT COMMUNICATIONS

AMONG OVERLAPPING COMMUNITIES OF COMPUTER

NETWORK USERS

PRIORITY INFORMATION

This application is a continuation-in-part, and claims priority to, the U.S. patent application filed November 17, 1999 entitled, SYSTEM AND METHOD FOR IN CONTEXT COMMUNICATIONS AMONG OVERLAPPING COMMUNITIES OF NETWORK COMPUTER USERS by the inventors of the present application, specifically, Claus Spacil, Chris Wiener, Peter Madams and Pavel Shabalin.

BACKGROUND OF THE INVENTION

1. Field of the Invention The invention relates in general to computer network based communities in which groups of users of computer network access devices communicate over a network, and more particularly, to management of user participation in such network communities.

2. Description of the Related Art Computer networks have become almost ubiquitous. Today, perhaps the most famous network is the Internet that interconnects information access devices, such as personal computers, for example, throughout the world. It is possible to locate and access information stored at myriad different network address locations on the Internet or on other local area networks and wide area networks that may or may not form part of the Internet. Moreover, there is a variety of different types of network communications available to network users who wish to participate in network based communities, and there are many ways in which to form network communities.

Network addresses specify the location of information objects on a network. An information object, for example, may be a file or any other unit of information accessible over a network. Each information object has its own network address. Generally, when the user of a network access device wishes to access an information object over a network, the user must specify the network address of the desired information object. For instance, a user may browse the Internet by selecting interface objects that appear on a series of web pages that the user visits. An interface object, for example, may be text, graphic, or perhaps even an animated region that appears on a web page. By selecting an interface object that has a network address associated with it, such as a hypertext link for instance, the user can access an information object specified by the associated network address.

Network addresses typically are partitioned into different components that specify different parts of the network address coordinates of an associated information object. An Internet network address may be specified with a uniform resource locator (URL). A domain name portion of a URL specifies the network domain in which an information object is located on a network. For instance, the hypothetical domain name,

"www.LNP.com," has components that specify the domain name of companies in the USA (com), a hypothetical company (LNP) and a computer (www). Thus, the aforementioned domain name specifies the world wide web server computer of the company designated as LNP which is located in the USA. When a user of a network access device wishes to access information located on the

Internet, for example, the domain name portion of a URL of the sought after information typically is sent out over the network to a domain name server (DNS). The DNS associates this with an internet protocol (IP) address that is used to access the desired information and return it to the requesting user. Generally, there is a one-to-one correspondence between domain names and IP addresses. Although there are cases where several domain names correspond to the same IP address or where one domain name has several IP addresses associated with it. One example of this is a particularly busy (i.e., heavily accessed) domain that may be served by multiple computers in order to manage the load of access requests. Another example is a virtual host, one computer that masquerades as several different domains.

Communication among network users has become one of the most visible features many networks. The Internet, for instance, can support an enormous variety of forms of communication. Examples include, email, chat, instant messaging, conference calls, and video conferencing, just to name a few. Chat services allow two or more users to exchange messages in a live interaction. Typical chat uses only text messages, each user types in their message and the chat system broadcasts it to all of the other users in real time, so that everyone gets to share in the on-line conversation. Chat systems can handle more complex objects than simple text messages, some support multi-point file transfer others add "joint web browsing" where one user inputs a URL which is broadcast to all other users and handed automatically to their web browsers.

Instant Message (IM) systems allow two users of computers on a network to exchange messages in real time. Typically, messages are simple text one user types in a messages and sends it "instantly" to the other user who can easily reply to the message in a similar way. Some systems support sending more complex objects such as images, documents or other files and some add streaming protocols that support live voice or video connection. Most IM systems maintain a "buddy list", a list of users to contact. Some present the on-line status of such buddies, that is, when a user is on-line each IM client makes this known to the user's buddies. It is important to know if a user is on-line.

Otherwise a typical instant message will not work. IM is akin to a chat system with only two users. Some systems actually merge the two into one program. Currently, one drawback with the use of instant message systems is that there is no standard protocol used by all providers of this type of system. There have been efforts to further enhance communications by providing a shared context for communication. The context, for example, may be a network accessible document that several geographically dispersed users may simultaneously access to discuss or to edit. Alternatively, the context may be a web page that users may annotate with notes that can be picked up and read later by other users. Notes services of this general type have been provided on the Internet by Third Voice, Inc., having a place of business in Redwood City, California, by uTok, Inc., having a place of business in Tel Aviv, Israel, and by Essential Surfing Gear, Inc. (esgear), having a place of business in San Francisco, California, for example.

U.S. Patent No. 5,864,874, entitled COMMUNITY CO-PRESENCE SYSTEM issued to Shapiro and U.S. Patent No. 5,818,084, entitled CO-PRESENCE DATA

RETRIEVAL SYSTEM, issued to Shapiro et al., provide data retrieval systems with a co- presence mechanism. According to the Shapiro patent, the co-presence mechanism permits two or more users who retrieve the same information object at the same time to become aware of each other and consequently to communicate with each other in real time. The data retrieval system enables a user who accesses a certain document to discuss it in real time, with others who might happen to access the document at the same time. "Co- presence" according to the Shapiro patent, is the capability to enable two or more users to be "present" at a "virtual place." ('874 Patent, column 1, lines 56-65). More specifically, according to the Shapiro patent, when an information access device requests an information object from a data repository, the information access device also informs a co-presence server that it has accessed the specific information object. The co-presence server then adds the information access device to a virtual place associated with the accessed information object. The information access device associates virtual places with accessed information objects. Thus, the co-presence server can maintain a virtual place for information objects accessed by the information access device. The co- presence server also can create a virtual place on demand when a user first becomes present at an information object, and can remove the virtual place when no one is present. ('874 Patent, col. 3, lines 38-55).

A virtual place of the general type disclosed in the Shapiro and Shapiro et al. patents, therefore, makes possible the changing of context for network communications with changing access to information objects. The context for communication at any given time can be a mutually accessed information object. Companies such as Hypernix Technologies Ltd., having places of business in Tel Aviv, Israel and New York, New York with its product, Gooey, and such as NovaWiz, having places of business in New York, and Hertzilya, Israel, with its product, Odigo for example, offer Internet users co-present at a mutually accessed information object the opportunity to engage in chat in the context of the object. Additionally, patents exist which describe systems which can overlay data on top of information objects without altering the information object in any way. One type of data which can be overlaid or attached to an information object or portion of an information object is an annotation or "note" which can consist of text data, voice data, video data, or other types of data. Patents which discuss these systems include U.S. Patent No. 5,826,025 entitled SYSTEM FOR ANNOTATION OVERLAY PROXY CONFIGURED TO

RETRIEVE ASSOCIATED OVERLAYS ASSOCIATED WITH A DOCUMENT REQUEST FROM ANNOTATION DIRECTORY CREATED FROM LIST OF OVERLAY GROUPS, issued to Gramlich; and U.S. Patent No. 5,832,263 entitled SYSTEM AND METHOD FOR IN-PLACE MODIFICATION OF INFORMATION RECORDED IN READ-ONLY STORAGE USING MODIFIABLE NON- VOLATILE

STORAGE ASSOCIATED WITH AN AGENT, issued to Hansen, et al. While systems of the general type described above generally have been successful, there have been shortcomings with their use. For example, neither Shapiro, et al. , Gramlich nor Hansen, et al. address the issue of how to associate the network address of the accessed information object with the location of the corresponding notes or co-presence server when considering a very large-scale network, such as the Internet.

Additionally, the systems described above provide no mechanism for filtering or discriminating between which other users a user of the system wishes to be aware of or interfered with. This can become a particularly difficult problem in the context of the internet which, as noted above, can have millions and millions of users. There are also other shortcomings with the use of systems of the type disclosed by

Shapiro, Gramlich and Hansen, et al. For instance, a user may wish to choose the set of users with whom he or she wishes to communicate depending upon the accessed information object that serves as the context of the communication. A user also may wish to communicate with one set of users in the context of an accessed information object at one time and may wish to communicate with a different set of users in the context of the same object at the same or at a different time. In other words, a user may wish to participate in different communities of users in the context of different information objects, or the user may wish to be able to choose which community of users to participate with in the context of any given information object. For instance, a user may wish to communicate with one community of users when searching for the Internet information about automobiles for sale. The information objects providing context for communications are likely to be automobile-related web pages. The same user may wish to participate with a different community of users when visiting an online site dedicated to restaurants and entertainment. The information objects providing context for communications probably will include entertainment-related web pages.

Moreover, a user might want to discuss investments with one community of users and may want to discuss sports with a different community of users. The information objects providing context for communications are likely to include investment-related web pages. Conversely, different providers of communication services may wish to target those services to different communities of network users. For example, one service provider may wish to attract users seeking financial services. Another service provider may wish to focus on users who want travel services. Yet another service provider may wish to foster cooperation among users interested in volunteering in various public interest projects. The participants in these different communities have different interests. Certain service providers may wish to promote the formation of communities of users around their communication services by catering to the interests of participants in such communities.

Additionally, annotations such as notes can be troublesome to use. For instance, in web discussion forums such as USENET, for instance, an information device user may post a note that poses a question. Generally, a user returns to the web site that hosts the discussion to find out whether another user has posted a note that replies to the question. Thus, the user typically takes the trouble to actually access the discussion forum web page again to learn whether or not a question has been answered. For in-context communications, of the general type discussed above, the problem of checking for answers to different notes posted in the different contexts of numerous different information objects can become much more severe since the notes may be scattered over many network address locations in a network For instance, a device user may leave different notes on different web pages of the Internet. A user then might have to access each different web page where he or she left a note in order to learn whether or not questions in such notes have been answered. This effort has the potential to be time consuming and tedious. BRIEF DESCRIPTION OF THE DRAWINGS Figures 1A-1C are illustrative functional schematic diagrams showing the general architecture of a presently preferred embodiment of the invention. Figure 2 is an illustrative functional schematic of the general architecture of a presently preferred embodiment diagram of the invention, which includes a service area directory structure and a community server directory structure.

Figures 3A-3K are illustrative functional schematic diagrams showing multiple information access devices accessing multiple combinations of information objects and community servers in accordance with a presently preferred embodiment of the invention.

Figure 4 is an illustrative drawing of an example service area directory structure in accordance with a presently preferred embodiment of the invention.

Figure 5 is an illustrative drawing of a server area directory structure which includes a backup service area directory structure and multiple cache service area directory structures in accordance with a presently preferred embodiment of the invention.

Figure 6 is an illustrative drawing of a process of determining whether a network address (or area) of an accessed information objects matches an address (or area) entry in a community server director structure in accordance with a presently preferred embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Moreover, in the following description, numerous details are set forth for purpose of explanation. However, one of ordinary skill in the art would realize that the invention may be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of the invention with unnecessary detail. Thus, the present invention is not intended to be limited to the embodiment shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein. Architecture

It is well known that multiple information access devices may connect to a network and request access to an information object. The information access devices need not be alike. For instance, an information access device may comprise a personal computer, cellular telephone, PDA, set top box, WebTV device, handheld wireless inventory device, server computer or other information appliance. Moreover, the information object may encompass almost any form that can be transmitted over the network. For example, an information object may be a file, web page, a video clip or a graphic. A file is a general type of information object that can encompass many specific types and formats of information. One characteristic of a file is that it has a network address where it can be accessed. A file might be accessed 'all at once' (as with a web page, or word processing document, or image) or it might be accessed as a stream (as with audio or video streams). In either case the file is accessed using a network address. Even a telephone conference bridge or a chat session, might be considered to have a network address, 1 -800-555-1234 as hypothetical example. The network, for instance, might include one or more local area networks (LAN), a wide area network (WAN) which handles data or telephone communications traffic or both, the Internet, a fixed network or a wireless network. Figures 1A-1C illustrate the general architecture of presently preferred embodiment of the invention, the general architecture is best understood through an example of the manner in which it operates. Figure 1A provides an example of multiple information access devices seeking the same context by accessing the same information object. Figure IB provides an example of the same multiple information access devices determining which community servers provide service in context of the accessed information object. Figure IC provides an example each of the multiple information access devices selecting from among the community servers they are registered to use in the context of the accessed information access device. Referring to the illustrative drawing of Figure 1A, there are shown multiple information access devices, 602, 604, 606, 608. The arrows 603, 605, 607 and 609 indicate that each of the multiple information access devices may independently request access to an information object 610 via an information object server, which may comprise a computer or other information access device (not shown), over a network, such as the Internet, for example, represented as a cloud 612 of routing devices and networked computers. It will be appreciated that the access requests may occur in close temporal proximity or with long time intervals between them. The respective access requests issued by the respective multiple information access devices are transmitted through the network 612 to an information object 610 capable of providing the requested access. Alternatively, for example, there may be multiple information servers (not shown) capable of providing the requested access, and different requests issued by different information access devices may be transmitted to different servers. In either case, one or more information servers receive the request to access the information object. An information server may respond to access requests, for instance, by returning a respective copy (or it may start a data stream flowing to the access device) of the requested information object to each information access device that independently transmitted a request received by such server.

As shown in the illustrative drawing of Figure IB, in accordance with a presently preferred embodiment of the invention, each of the multiple information access devices 602, 604, 606, and 608 independently requests from a service area directory server 614 information about services that may be provided in the context of the requested information object. Arrows 611, 613, 615 and 619 indicate requests for service area information which are transmitted through the network 612 to the service area directory server 614. The service requests may be closely spaced or widely separated in time. The service area directory server 614 provides access to information concerning one or more services that may be associated with the accessed information object 610. The service area directory server 614 responds to the respective requests for service information by providing via the network 612 respective service information indicated by arrows 611, 613, 615 and 619 to each respective requesting information access device. In one embodiment, the provided service information includes network addresses of one or more community servers, labeled 1, 6 and 15, shown in Figure IC that provide services in the context of the accessed information object.

In one embodiment of the invention, used in the context of the Internet, information access devices 602, 604, 606 and 608 include browser software and companion software.

The browser software accesses information objects such as information object 610 via information object servers (not shown). The companion software monitors the browser software to detect the network address of the information object being accessed. The companion software then commimicates with the service area directory 614 and community servers of the present invention.

A service area directory server may have information concerning one or more community servers that provide services in the context of a given accessed information object. As explained below, some community servers may provide services in the context of some but not all information objects. For example, the service area directory server 614 provides an illustrative directory 620 that provides network addresses of a set of twenty different community servers that can provide service in the context of the particular information object accessed via requests 603, 605, 607 and 609. For simplicity sake, these twenty network addresses are identified by the numerals 1 - 20.

Each of the information access devices 602, 604, 606 and 608 is configured to partake in services provided by a different set of community servers. More specifically, in a preferred embodiment, information each access respective device 602, 604, 606 and 608 maintains respective registration information 622, 624, 626, and 628 indicating the community servers it is registered to use. In this example, Information access device 602 is registered to partake in services provided by a set of community servers at network addresses 1, 6 or 20. Information access device 604 is registered to partake in services provided by community servers 2, 4, 6, 10 or 20. Information access device 606 is registered to partake in services provided by a set of community servers 3, 5, 6, or 15. Information access device 608 is registered to partake in services provided by a set of community severs 7, 9, 11, 12, 15, 17, 18, 19 or 20.

The user of an individual information access devices may partake in the services provided by one or more community servers for which he or she has registered. Referring to the example illustrated in Figure 1-C, arrow 630 indicates that information access device 602 forms a network connection with the community server labeled with reference numeral 1 at network address 1. Arrow 632 indicates that information access device 604 forms a network connection with the community server labeled with reference numeral 6 at network address 6. Arrows 634 and 636 indicate that information access device 606 forms a network connection with both the community server labeled 6 at network address 6 and with the community server labeled 15 at network address 15. Arrow 638 indicates that information access device 608 forms a network connection with the community server labeled 15 at network address 15. Thus, only information access device 602 partakes in services provided by community server 1 in the context of the accessed information object 610. Both information access devices 604 and 606 partake in services provided by community server 6 in the context of the same accessed information object 610. Both information access devices 606 and 608 partake in services provided by community server 15 in the context of the same accessed information object 610.

Each information access device in this example, therefore, may partake in services from among any one or more of the community servers in the set of community servers for which it is (or its user) is registered. For instance, each of the illustrated information access devices 602, 604, 606 and 608 is registered or configured to partake in the services of the community server at network address 20. However, none of the devices has made a network connection to the server at network address 20, and therefore none of them partakes in those services. Moreover, information access device 606 is registered to partake in services provided by any of a set of community servers at network addresses 3, 5, 6, or 15. Device 606 has established network connections with community servers at network addresses 6 and 15, and therefore, partakes only in the community services provided by those two community servers. Figure 2 provides an illustrative example of the architecture of a service area directory structure associating an information object network address (or address range) with multiple community servers and a community server directory structure associating the information object network address with particular communications in accordance with a present embodiment of the invention. The service area directory structure is encoded in computer accessible storage media in a service area directory server. The community server directory server is encoded in computer accessible storage media in the community server. The architecture of the service area directory structure and the community server directory structure are illustrated through their operation in connection with user device access of a representative information object. For example, information access device 616 forms a network connection 618 across network 612 with server device 620 in order to access an information object at network address NA-x which is served by server device 618. The information access device 616 forms a network connection 622 across the network 612 with service area directory server 624 located at network address NA-SAD. The information access device 616 requests information about which, if any, community servers provide service in the context of the accessed information object at network address NA-x. The service area directory server 624 provides a directory structure 626 which associates respective network addresses patterns, NAP-1 through NAP-51 in this illustrative example, with respective community servers that provide services in the context of network addresses NA-x. The service area directory server 624 reports to device 616 the network addresses of the community servers that provide services in the context of network address NA-x. In this example, there are fifty-one such community server network addresses.

In a present embodiment of the invention, the information access device 616 determines which if any of the community servers identified as providing service in the context of the accessed information object the device 616 is registered to use. In this example, the device 616 is registered to use the community server labeled 3117 at network address NA-3117. The information access device 616 forms a network connection 628 with community server 3117 located at network address NA-3117. The device 616 notifies the community server 3117 of the network address NA-x of the accessed information object. The community server 3117 provides a directory structure 630 that associates respective network addresses (or network address areas) with respective service objects. In the illustrated example, network address NA-a is associated with service object SO-a; NA- b is associated with SO-b; NA-x is associated with SO-x; and NA-y is associated with

SO-y. The community server directory structure 630 respectively associates service objects SO-a through SO-y with respective detailed information Info-a through Info-y. Respective service objects provide brief information concerning communications in context of the associated objects. For instance, SO-x might provide location, author and time stamp of notes attached to the information object (e.g., a web page) at network address NA-x. Respective detailed information provides additional details about the communications identified by an associated service object. For example, the information of Info-x might provide the actual text of notes identified by the service object SO-x as being attached to the information object at network address NA-x. Alternatively, for example, a service object might identify users who are currently "present" at a given network address, and the detailed information corresponding to such service object might provide an email address or an IP address of identified users.

In operation, the community server 3117 returns to the user information access device 616 service object information associated with the information object accessed at network address NA-x. The information access device 616 presents the service object information to the user. If the community server 3117 provides a notes service, for instance, the service object SO-x information might indicate, for example, who left notes on the information object at network address NA-x and when such notes were left. If the device user wants to read a particular note, for example, then the device 616 uses the network connection 628, which may be persistent or transitory, to access the detailed information Info-x pertaining to the particular note. On the other hand, if the community server 3117 provides an instant message service, for instance, the user can use the service object SO-x information to observe who is currently available to send and receive instant messages in the context of the accessed object at network address NA-x.. If the user wishes to send an instant message to another user who is present in the context of the information object at NA-x, the device 616 uses the network connection 628, which may be persistent or transitory, to glean the detailed information Info-x concerning the email or IP address or other contact information for the desired other user.

More specifically, in one embodiment, the community server index structure comprises a table which includes a plurality of entries. Alternatively, the index structure could be implemented in whole or in part as a tree structure. Each entry includes a network address field, which serves as a match target, and a result field, which includes a service object. There may be several different service object type fields. Preferably, though not necessarily, a community server provides only a single service, though a service provider

(e.g., company, government, etc.) will likely provide a number of different services. Each service object provide service information that pertains to associated network addresses. A notes service object in a current embodiment includes a reference to a collection of notes anchors. A synchronous communications service object in a current embodiment includes a list of userlDs currently present at the accessed information object, i.e. the user presence information. A community server transmits the contents of these lists (anchors, presence), which constitutes service information, to a requesting information accesses device. The device user can select an anchor or select another user's ID from the presence list and request the community service provider to actually provide a desired service, i.e. a notes, instant messaging, chat, keyword, or conference. Although, the index structure also could be implemented using a relational database management system.

It will be understood that in the above example, the illustrative community server directory structure 630 of Figure 2 is explained in the context of two different servers that can be implemented using the same basic community server directory structure, a notes server and a an instant message server. Moreover, it will be appreciated that multiple community servers might operate on different network addresses served by a single physical server computer. Alternatively, multiple servers may in fact be implemented on multiple different physical server computers. As yet another alternative, in a TCP IP system, for example, multiple servers may be implemented as sub-systems listening on multiple different ports of a server system. Since the service area directory server maintains associations among network addresses of accessed information objects and community servers that serve such network address and corresponding information objects, the information access devices themselves need not maintain the associations among information objects and community servers. This is beneficial since from time to time there may arise a desire to change the services provided in the context of one or more information objects. Such changes may be communicated to individual information access devices via connections between the service area directory server and the individual devices at the time when such devices request service information from the service area directory server. In this manner, services can be readily added, dropped or changed, without the need to individually notify information access devices until they request services in the context of an information object with a new or changed association.

Thus, a variety of different services may be available over the network 612 in the context of any given information object accessed over the network. The service access directory server manifests this variety by maintaining one-to-one and one-to-many associations between information objects and community servers. A one-to-many relationship signifies that multiple services are available in the context of an accessed information object. As a result, a user of an information access device may choose from among different services when the user accesses different information objects.

Alternatively, the same user of an information device may choose to use a single service as the user accesses different information objects. This is significant since any given service may be more appropriate in the context of one information object than in the context of another information object. The system of the present invention, therefore, permits the user of an information access device to select the service the user believes to best suited to his or her needs in the context of any given information object.

It will be appreciated that the services provided by the different community servers may be quite similar in many respects and quite different in others. Moreover, different users may have different preferences for different services. The community servers may be under the supervision and control of different providers such as corporate, government or educational. A user of an information access device may choose a service or services that he or she wishes to partake in the context of a given information object at a given time. Consequently service providers may have to compete for user participation in their respective services. This competition would represent a benefit to users. Conversely, service providers may benefit by focusing their services to meet the particular needs of targeted users. By targeting services appropriately, a provider could attract users it desires to its services. Thus, on the one hand, a service provider has an opportunity to continue to attract a user participation in its service even as users access one information object after another, as they might do when they surf the web for example. On the other hand, a user can have the opportunity to readily switch from one service to another as the user surfs the web, for instance, by changing community server connections.

The services provided by community servers in a presently preferred embodiment of the invention include communication services such as notes, instant messaging, chat, conferencing, email, or even auctions, for example. Notes also have been referred to as "annotations" and can take many forms. Generally, however, notes refer to data which is associated with an information object or portion of an information object and which may be created and accessed by users of different information access devices who access the information object. For instance, a note can be just plain text. However, a note might include no text and might have a document or a web page or a voicemail or videomail message attached to it. Additionally, in a preferred embodiment and as will be discussed in more detail below, the notes are not located at the information object. Rather, they can be overlayed onto the information object by a server in another location. In this way, the notes do not alter the information object in any way.

As mentioned above, an information access device connects with a community server in order to partake in the services provided by the server in the context of an information object. In one embodiment of the invention, an information access device informs the community server of the network address of the information object for which context related services are sought. An a preferred embodiment, the information access device also will deliver registration identifying information which, in a present implementation, can include a userlD and other information discussed in detail below.

As discussed above, the community server searches its directly structure to determine whether there is an entry for the network address (or network address range) provided by the device. In the case of a notes community server, for example, the community server searches for a match to the network address provided by the information access device. If no matching entries exist, then a null response is returned. The community server also will check the userlD against a list of registered users, if this community server service requires registration before a user may enjoy access to notes. Some community servers may require registration to read a note; others may not. Other community servers might require registration only to post notes but not to read notes, for instance.

In the case of a "presence" community server, such as an instant messaging service, the community server similarly searches its directory structure for a network address match. If there is no match, then no other user is "present" for this community server for the network address of the accessed information object. The community server creates a new entry in the directory structure to indicate "presence" at the network address of the accessed information object. The incoming userlD is added to the "presence" service object list. For "presence", a new entry is created immediately so that other users can learn of the arrival of a new user in the context of the accessed information object. For notes, a new entry is created only when, and if, the companion software of the information access device comes back later with a new note. Again, the userlD may be used to screen for registered users as well. Thus, a community server may transmit to an information access device service information in the form of one or more service objects. A service object may comprise a list of anchors, a list of userlDs, or other information which is used to implement a service such as a keyword or videoconferencing service, for example. In the case of instant messaging or email services, user identification information in the list can easily be provided in sufficient detail so as to enable further communication with other users. For example, an IP address or email address can be provided. As mentioned above, certain community servers may also return a reference to an actual communications device that is implementing service in context of the particular information object, i.e. the address or other access information for a chat room or a video conference for example.

Thus, in one embodiment of the invention, community servers provide in-context communications among members of a community. Communication might be synchronous (IM, Chat, conference) or asynchronous (Offline-IM, email, notes). Alternatively, however, the community server itself may not actually provide the commumcation. The community server might instead merely provide interfaces to external communication systems in the context of one or more information objects.

When using the community communication system, information about other users of the system becomes available from time to time. Examples include, the author of a note, an entry in a buddy list or the presence of another user accessing the same information. In a present embodiment, for example, of the invention, user interface software operative on an information access device causes an icon representing another person to be displayed for the user who can select the icon and choose from a menu of communication functions. In a present embodiment, this menu is extensible. Third party tools can be readily added the menu easily. More specifically, for example, in response to an information access device request for services issued over a network connection to a community server, the server provides: (1) positive or negative response about a network address match; (2) if positive, a service object which may include a list of anchors and/or a list of userlDs; (3) optionally, an address of a (perhaps third party) commumcation process (for chat, conference, etc). In a present embodiment of invention, upon receiving a list of anchors, for example, the access device will "annotate" the (user interface) presentation of the information object

(such as a web page for instance) showing anchors wherever a note previously was attached by another user for instance. Upon receiving a list of userlDs of users who currently are "present" at an accessed information object, the information access device makes available this presence information to the user. Of course, the user may have to prove he or she is registered before the server will grant access to these services.

An information access device user may select from among the anchors or from among users indicated to be present. If a user selects an anchor, the access device will send information that identifies the selected anchor to the community server. The actual note contents corresponding to the selected anchor will be returned by the community server to the access device. The note contents then can be displayed by the access device for viewing by the user. If a note involves video or audio, these also will be made accessible to the user. Alternatively, the note might provide a link to another web page, or might be used to access some other information object. If a note includes a dynamic keyword link, then the user access device connects directly to the information object of the dynamic link.

If a user wishes to create a note he or she might select some part of a display of an information object which will serve as an anchor. The user specifies the content of the "note". This might simply be some text, or perhaps some structured text such as a word processing document or a web page, or it might be a more complex object such as an image, a voicemail or any other information object. The information access device transmits the new anchor information and the note contents to the community server together with the accessed information object's network address and a userlD. The community server stores the new anchor and note and associates them in its index structure to the network address of the accessed information object. In other words, the note is stored in the context of the accessed information object.

Moreover, it will be appreciated that when provided with sufficient information to identify a user device who is "present", a given information access device may be able to send instant messages to that user. This represents a form of synchronous (real-time) communication. In order to achieve such instant messaging the given device may form a direct connection to that other user's access device or sends the message through a server to that user (which is likely the case with firewalls and situations where a direct user-to-user connection is not desired). In one embodiment, the user of the given information access device may select another user from among a list of users indicated to be "present" in a certain context. The given device opens a dialog box in which the user can input the text of a message (together with any "attachments", for instance documents, files, images, etc.) In a present embodiment of the invention, a unique user ID is assigned to each device user. This unique user ID is a form of user information. In a current embodiment, the unique userlD assigned to each user is the only use information required for the system to operate. With the userlD, any service component can access the user's home server. As discussed in detail below, a home server is server with which a user of the system of the present invention registers and logs into to access the system of the present invention. The home server includes information about the user other than the user's userlD. For good performance, some data will be carried together with the userlD as part of the user information, thus saving accesses to the home server. One important example involves the IP address of a user's information access device. To communicate over the Internet, the IP address of the target is required. IP addresses are often assigned dynamically so that the IP address for a user might change from day to day or even session to session. (A session is defined as the time from when the user logs-in to the network until they log-out). Internet communication software such as voice-chat or data-conference tools need only the IP address of the target user in order to operate. The user information data can contain the IP address since it is small amount of data the overhead of always sending it is low. With this available, it is very simple to start the third party software, passing the IP address as a parameter.

It should be noted that IP addresses might be withheld from the user information data for reasons of privacy. In which case, server facilitated connections can be used.

Another type of service available to users through the system of the present invention includes Dynamic Keyword Links. Hyperlinks (sometime just called links) are common on the World Wide Web and other hypertext systems where a user selectable connection is displayed linking an interface object (for example a word, several words, images, or other objects) to some other object. This simple yet powerful technique allows a person to create cross-references all over an entire network, including all and any of the World Wide Web in conjunction with an internal private network perhaps, which has great value for commerce, education, entertainment and many other purposes.

Dynamic Keyword Links appears as hyperlinks to the user yet they do not require anyone to alter the interface object itself. This simple yet powerful techmque allows a provider of a community server to automatically create cross-references from anywhere on an entire network, including from interface objects that the provider itself does not have access, to some information object preferably related to the community service itself. Examples include, commerce, advertising, auctions, reference and other applications yet to be discovered.

In a mechanism for implementing dynamic keyword links the community service providers provide a set of keywords and the corresponding network address (for example a URL) that will be used as the target of the link. Keywords are stored as anchors in a form similar to that used for annotations. In addition, for each keyword, the network address pattern defining the area of the network where the keywords will apply is given.

Dynamic Keyword Links are created and managed at the community server by a service provider. A community server directly includes entries for each network area where a given set of keywords will apply, that is, a network address pattern is added to the directory (or index). Typical patterns might be "http://[*]" to map the entire http: web, or "http.//[*]. xyzcorp.com" to map the entire web site at a corporation. Keywords are defined and stored as anchors and stored in the service object together with the target address (compare this with notes where the anchors are stored in the service object together with a reference to the annotation)

When a user accesses some information at a network address, a check with the service area directory will show whether that address is being served by this community server. If it is, a connection is made to the server and the network address is matched with the network address patterns in the community server index. If the network address matches one or more of the patterns that have been created for keyword, the corresponding service object containing the keyword anchors and target addresses, is returned to the user. The user's information access device searches the information object for occurrences of the keyword anchors and automatically marks them as hyperlinks. If the user selects the hyperlink, the anchor contents are used to access the target address Typical network address patterns for keywords cover the entire network and would be accessed every time that the community server is references, caching techniques are used to reduce the overhead of such accesses. Also, searching the accessed information object for occurrences of the keyword anchors use the same mechanism as the overlaid annotations. In the case of annotations, it is important to be able to find where the annotation was anchored even when the accessed object has been altered somewhat and the anchor's location has moved. Of course, the anchored location may be removed altogether in which case the annotations are "orphaned" and can be ignored. In the case of keywords, they may not exist on the object either and they will be ignored. Examples of Information Access Device Users Joining and Departing Communities and Changing Information Object Contexts

Figures 3A through 3K illustrate several examples in which device users form network connections with community servers to join communities and access information objects to communicate with other community members in the context of an information object.

Referring to Figure 3A, information access device 650 first accesses information object 652. Second, information access device 650 provides the network address NA-x to service area directory server 654. As illustrated by index 656 of service area directory server 654, in the example shown in Figure 3A, there are nine community servers which service area directory 654 associates with information object 610 having illustrative network addresses 52, 53, 54, 58, 59, 60, 64, 65, and 66. In Figure 100.5A, user access device 650 accesses the community server at address 59.

In Figure 3B a second information access device 651 accesses information object 610. Information access device 651 then queries service area directory server 654 for addresses of community servers which provide services in the context of information object 610. Then, along with information access device 651, information access device accesses the community server having address 59. Thus the users of devices 650 and 651 are members of the community of users registered to use the services of server 59. They can communicate in the context of information object 610 at network address NA-x.

After information access device 651 has accessed information object 610, and information object 650 has accessed the community server at address 59, the connection between information access device 650 and information object 610 may or may not persist depending upon the nature of information object 610. If, for example, information object 610 is a single graphic, the connection may be severed. However, if information object 610 is some type of streaming connection, such as a video or audio stream, the connection will persist.

Figure 3C shows the situation of Figure 3B and further illustrates an index 59a of the community server at network address 59. As shown, index 59a includes a plurality of entries, each of which associates a network address with a service object. Specifically, as shown, network addresses NA-A, NA-B, NA-C, NA-x and NA-y are associated with service objects SO-A59, SO-B59, SO-C59, SO-X59 and SO-Y59, respectively. As discussed above, these service objects could, for example, be chat services, notes services, presence services, videoconferencing services, or any other synchronous or asynchronous services. As shown by arrows 802 and 804, both information access device 650 and 651 can simultaneously partake in the service of service object SO-X59 provided in the context of information object 610 at network address NA-x. The users of information access device 650 and 651 can each be aware that the other user is accessing information object 610 and, depending on the nature of service object SO- X59, can preferably communicate with one another. Thus, if a business, government, educational, or other group sponsored the community server at address 59, users of information access devices 650 and 651, who may each have an interest in common with the business, government, educational or other group, could be made aware of each other and communicate with one another.

It should also be noted that, as shown by community server directory 59a, it is possible that a single community server provide services in the context of different information objects; specifically, information objects at network addresses NA-A through NA-y. In this way, a sponsor managing a community server can offer services in the context of as many different information objects (e.g., many different web pages).

In Figure 3D, information access device 651 forms a network connection 806 with the community server at address 54. In the manner described above with respect to information access device 650 in Figure 3B, this connection is made after information access device 651 has queried service area directory 654 for the addresses of community servers offering services in the context of information object 610. Additionally, as represented by arrow 808, information access device 651 continues to access information object 610. Thus, user information access devices 650 and 651 both access information object 610, but they no longer share in context community services, since they have accessed different community servers. In this way, for example, a sponsor offering services from community access server at address 59 can do so without having the user of an information access device using the sponsor's services aware of or distracted by services offered by a second sponsor, say one offering services on community server at address 54. Additionally, by providing additional community servers, as many sponsors as would like may offer services associated with information object 610.

In Figure 3E information access device 652, accesses information object 611 which is located at network address NA-y on a server device (not shown). Device 652 accesses service area directory 654 to determine which community servers offer services in the context of information object 611. As shown, service area directory 614 includes index 657. In the example shown, index 657 shows that there are six community servers providing services in the context of information object 611 including those at addresses 54, 55, 60, 61, 66, and 67. This information is returned to information access device 652 which, in the example shown, accesses the community server at address 60. Because the user of each information access device is using a service provided by a different community server, the users will preferably remain unaware of each others presence on the web.

Thus, in Figure 3E devices 650 and 651 access the same information object but access different community servers, and device 652 accesses a different information objected and yet another community server.

Figure 3F illustrates the system shown in Figure 3E after information access device has accessed the community server at address 60. Specifically, information access device 652 preferably no longer remains in contact with service area directory 654. As noted above with respect to Figure 3B, after information access devices 650, 651 and 652 have accessed community servers 59, 54 and 60, respectively, the respective connections between information access devices 650, 651 and 652 and information objects 610 and 611 may either be cut or persist, depending upon the nature of information objects 610 and 611. In Figure 3G, information access device 651 cuts off its access to information object 610 and accesses information object 611. Information access device 651 then queries service area directory 654 for addresses of community servers which provide services in the context of information object 611 having network address NA-y. Service area directory 654 returns the list of community server addresses shown in index 659. Information access device can then select from the community servers with which it is registered. As shown, information access device selects community server at address 54. As shown in Figure 3 A in index 656, the community server at address 54 also provides services in the context of information object 610 having network address NA-x. Thus, in Figure 3G, devices 651, and 652 access the same information object at network address NA-y, but partake in different server communities, 54 and 60. Meanwhile, device 650 accesses the information object at network address NA-x and partakes in community server 59 services.

Figure 3H, illustrates the status after information access device 651 has accessed the community server at address 54. Specifically, information access device 651 need no longer remain in contact with service area directory 654. In Figure 31, illustrates the information access device 650 has severed its connection with the community server at address 59 and established a connection with community server at address 60. It is to be understood that it was not necessary for information access device 650 to query service area directory 654 before accessing the community server at address 60. This is because, as explained with respect to Figure 3A, all of the addresses of the community servers providing service in the context of information object 610 at network address NA-x were provided to information access device 650 at the time information access device 650 first queried service area directory 654. And, preferably, information access device 650 caches this information so that it may later use this information to change services. In this way, if a first services provider manages the community server at address 59 and a second services provider manages the community server at address 60, the user of information access device 650 can switch from the services provided by the first service provider to the service provided by the second service provider without having to access service area directory 654 again. Thus, both devices 650 and 652 partake in community server 60, but in the context of different information objects. Device 650 has accessed the object 610 at NA-x, and device 652 has accessed object 611 at NA-y. More specifically, Figure 31 also shows community directory 60a in which service object SO-x60, associated with information object 610 at NA-x, and service object SO-y60 is associated with information object 611 at NA-y. Arrow 809 indicates a network connection on which device SO-x60 information. Arrow

811 indicates a network connection on which device 652 receives SO-y60 information.

In Figure 3 J, information access device 650 cuts off its connection with information object 610 and accesses information object 611. Assuming that information access device has not previously accessed information object 611, or at least not recently accessed information object 611, information access device preferably queries service area directory

654 for a list of the addresses of community servers providing services in the context of information object 611. Service area directory then returns the list shown in index 659 and information access device 650 selects the community server at address 60 and establishes a connection therewith. Figure 3K, shows that after information access device 650 connects with the community server at address 60, both information access device 650 and information access device 652 remain connected (either a persistent or transitory connection) with the community server at address 60. Further, both information access devices 650 and 652 are accessing information object 611 having network address NA-y. And, as indicated by arrows 813 and 814, both information access devices 650 and 652 access service object SO-y60 associated with the information object 611 having network address NA-y. Thus, the respective users of information access devices 650 and 652 can share in the services of community server 60 in the context of information object 611. The user of device 651 partakes in the services of community server 54 in the context of information object 611.

Example Communication Protocols

The following section summarizes information transfers (protocols) in three illustrative situations in a current embodiment of the invention:

(1) notes

(2) device-device communication

(3) server based communication.

Communication using notes, involves just one device at a time. Notes communication is asynchronous. Real-Time Communication is not required.

Direct communication from device to device is synchronous. Server-based communications between one or more devices, can occur synchronously. Server based communication has several benefits over direct client-client communication although there may be some additional overhead incurred when using a server. Such overhead usually is small and the benefits often justify the server based communication. A first benefit is that the first connection during communications may be made from client device to server and not server to client device. This is valuable when used with firewalls. Firewalls are designed to control incoming connections and only allow specific ones. Outgoing connections (from client to some public server) are considered safe and are allowed in all but the most secure systems. A second benefit is privacy. With server based communication, there is not a need for each client to know the actual network address of the other devices. A third benefit is performance. With multi-point communication, i.e. with three or more client devices, the server can broadcast copies of incoming information from each client device to all of the other client devices. Typically, servers are located at points a the network where high bandwidth is available making this type of broadcast very effective. The alternative of using direct client-to-many-clients broadcast puts extra load on the bandwidth available at each client. Typically, client devices are connected at end-points in the network, not the high bandwidth nodes within the network (where the servers are usually found).

The example communication protocols are as follows: 1) Notes

Overlay Annotations

A present embodiment of the invention includes the capability to overlay (with markers) any information object that is accessed over a network, and this is achieved without need to access the object directly, or need to have permission from the owner of the object. The markers are stored at another place on the network referenced by the network address of the "marked" information object. No connection is ever made between the information object store and the markers store. An information access device has additional capabilities added to it using the companion software, mentioned above, that performs a number of functions:

• Observes the network address of information objects that the user accesses • Sends these addresses to the server where markers are stored

• Retrieve a list of "anchors" from that server that describe the markers and some other service

• Overlays the display of the information object with the markers, giving the appearance to the user that the object itself is marked. • Intercepts user access to a marker (perhaps a mouse click) to access the service(s) described in the anchor, which take place IN-CONTEXT of the underlying object

• Typical services are community communications such as chatting with other users on-line and in-context or leaving messages for other users off-line, but again, in context of the underlying object.

This is a powerful mechanism that can be used for many different purposes. One example is annotations or notes, whereby different users can access any object over the network and (apparently) annotate it. Other users can see these annotations, and make their own, reply to questions, join in a discussion or work collaboratively; always in the context of the underlying obj ect. Note, the underlying object is never altered, no derivative of the object is created; annotations are only displayed to the user in context with display of the accessed object.

The computer program implemented process for accessing and creating notes are as follows:

Accessing a Note a. User selects an anchor. b. Information access device (or client) sends information about the anchor to the server. c. Server accesses the note in the database and returns it (and perhaps any attached objects) to the device, d. Device displays the note and attachments to the user. Creating a new note a. User selects a new anchor (e.g., text, image, object, files, document, whatever). b. Information access device collects user input for the note (e.g., text, images, attachments, whatever). c. Device sends the network address of the accessed information object and the new anchor and the contents of the note, to the server. d. Server creates a new entry in the index structure for the new anchor and notes (if required) and adds the new anchor to the list of anchors and stores the note in the database (together with any attachments). A reference to this database entry is stored in the new anchor. 2) Client device-to-client device based communication a. User selects one or more users he or she wishes to communicate with, from an access device presentation of the "presence" information, i.e. the list of users "present" in the context of a given information object. b. User selects from a menu the type of communication to establish, such as instant messaging, email, chat, conference, etc. The menu could also include third party software communication tools. c. Device presents the user with a dialog box where the user can input "messages". d. In the case of asynchronous communication, e.g. email, the device will send the user's message using the appropriate process. e. In the case of synchronous communication, e.g. instant messaging, chat, conference, the device will send the user's message directly to the selected users. f. Comment: In both cases d) and e) we assume that the user "presence" information contains sufficient information for the device to effect the communication. This might be the IP address of the devices where each user is connected. For email, it would be the email address of the user. If for some reason that information is not available, then communication could change to use server-based connections. The choice of direct client connection or server-based connection will (usually) be transparent to the user; the device operations are, of course, very different in each case. Alternatively, certain servers may only provide for server based communication. g. Additionally, a user may wish to keep information such as email address or IP address private. As discussed above, when using client-client communications, this type of information may not be able to be kept private. However, when using server-based communications, discussed below, this type of information can be kept private and a user need only know the userlD of a recipient. The email address or IP address of a communication recipient can be kept in the server. 3) Server based communication a. User selects one or more users who are "present" and who he or she wishes to communicate with, from the presentation of the presence information, i.e. the list of users present in the context of a given information object. b. User selects from a menu the type of communication to establish, such as instant messaging, email, chat, conference, etc. The menu can also include communications systems provided by third parties. c. If the user is initiating the communication, the communication "forum" will have to be created either by the third party system or in the community server. d. Device presents the user with a dialog box where the user can input "messages". e. Device sends the message to the server, which can broadcast the message to other users who have a connection to the server in the context of the given information object. f. As discussed above, server based communication allows a user's e-mail address or IP address to remain private. An originator of commumcation only need include the recipient's unique userlD in a communication. The server can retain the email address or IP address of the recipient keyed to the recipient' s userlD.

Hypothetical Examples of Shared Context Network User Communications

An advantage of the present invention is the ability of information access device users to employ the services of the community servers in the context of information objects accessed over a network. In one embodiment, community server services enable users to communicate directly with each other through notes, instant messaging, chat or conferencing, for example. Providing these communication services in the context of an accessed information object can give users a shared frame of reference for their communication. Consider, for example, an information access device user searching the Internet for an automobile to purchase. The user may visit several web sites and view web pages information about different vehicles of interest to the user. The pages are likely to promote the vehicle and provide numerous details. As the user visits a page, he or she may post notes associated with a vehicle featured on the page that ask questions or make observations about the vehicle. The user can post notes relating to vehicles as the user moves from page to page through the network. Alternatively, as the user moves from page to page through the network, the user may come upon notes posted previously by other users. The user may choose to read these notes, which may pose questions or may comment about some of the vehicles the user has been researching. The user also may reply to some of these notes. In fact, some of the notes might even answer questions posed previously by the user. Thus, users can communicate in the context of accessed information objects, in this example web pages dedicated to automobiles. As another example, two or more information access device users may access the same web page (or web area) at the same time. These users may wish to have an instantaneous dialog in the context of the web page. For instance, a web page may provide a document such as electronic blueprints for a new aircraft engine design. Several geographically dispersed design team members may wish to discuss technical details of the design. Each such team member will employ an information access device to visit the web page with the design on it. In that manner, all of the members can view design together. While they view the design, they can discuss it through instant messaging or by setting up a conference call for example. Thus, team members can engage in real time discussions in the context of an accessed information object, in this case a web page (or web area), that is dedicated to an aircraft engine design.

Network Name Area Allocation Through Network Name Partitioning

The present invention includes the ability of users to participate one or more communities of users and the ability of different service providers to create different communities of users. Users, for example, may choose to communicate with other users likely to share a common interest. Moreover, users may wish to change communities depending upon their interest at the time. For example, they may wish to participate in one community of users when seeking to make vacation plans. They may wish to participate in another community when seeking to invest in stocks. Conversely, a service provider may wish to sponsor communities of users who are likely to share a common interest. For example, a travel agency may wish to sponsor an on-line community centered on vacation travel. The service might offer travel packages to users who register for the service. The vacation travel service provider might even use information gleaned from inter-user communications to among community members create travel packages such as group tours.

Alternatively, for instance, a stock brokerage may wish to sponsor an investment advisory service. The service may offer advice and services to users who register for the service. It might take orders to trade, or give prompt notification of market changes that need immediate response from the user. This ability of a user to participate in communities of other users having similar interests can provide a filtering function. Specifically, a user may discriminate among the millions and millions of others users on the internet

The association of information access device users with communities is achieved in part through mapping of network addresses to sets of one or more community servers, that is, servers which offer services in the context of an information object. As explained above with reference to Figures 1A-1C and 3A-3K, when a user access device accesses an information object on the network, it also requests, from a service area directory server, community server associations with the network address of the accessed object. The service area directory server may return to the requesting device the network addresses of multiple community servers that provide service in the context of the accessed information object. Thus, there may be multiple community servers to choose from for communication services in the context of the accessed object. Each community server serves a different commumty of information access device users. A user may be registered to use more than one community server. In other words, the user may belong to more than one community.

Preferably, the user belongs to a different community for each community server he or she is registered to use. Such a multi-community user may choose the commumty server, and thus the community, with which the he or she wishes to communicate in the context of an accessed information object. Thus, network names of accessed information objects are used to identify to an information access device user a set of one or more communities in which the user may communicate in the context of the accessed information object.

Network address patterning is employed to demarcate user communities. Referring to the illustrative drawing of Figure 4, there is shown an example of an illustrative service area index structure provided by the service area directory server. The service area index structure is shown as a table, but it can be implemented as many related tables in a relational database instead. The first entry of each row in the illustrative directory is a network address pattern. Each pattern comprises at least a portion of a network address that may be employed to access information objects over a network. The network address pattern designates the portion of the network that is served. The second entry in each row identifies the network address of a community server that provides service for the information objects with network addresses that corresponds to the network address pattern in the first entry of the row.

A service provider who desires to establish a community of users may sponsor this community server. A community is generally a group of users who access services provided by a single sponsor, and who preferably share a common interest which can form the basis of the community. The community server is preferably managed by the sponsor in as much as the sponsor decides the nature of the services offered by the server and the portion of the network across which the services will be provided. The portion of the network across which the sponsor provides services is defined by the network address pattern or patterns which are included in the service area directory as being covered by the community server managed by the sponsor. It will be appreciated that one physical computer may host multiple community servers. It is also to be understood that a single community may be spread across multiple servers or be based in only a single server.

The third entry in each row identifies the service provider who sponsors the community server in the second entry. This information is useful to user of an information access device since it identifies the service provider (or community) associated with the network address in the second entry. As explained below, this service provider information facilitates scaling of the service area index. The fourth entry in each row identifies the service type provided by the community server identified in the second entry. The fifth entry in each row identifies the desired subject of communications for the community server identified in the second entry. Users may be encouraged to adhere to the desired subject, if only through the force of common rules of etiquette. A server network address may in fact identify a composite server that, in effect, responds to information access device requests for different types of services by routing the requests to the appropriate sub-systems of the server. For instance, the server identified in the first row of the index structure at NA1, may route requests for different types of services to server sub-systems. In that case, the service type entry in the index structure could include further routing information to permit an access device user to form a connection to the appropriate sub-system. This further routing information would be returned to the user along with other information in the table. In the case of an implementation using TCP/IP sockets, for example, the routing information might include port addresses. Thus, in the first row, in the service type entry, there would be port addresses associated with each of the chat and notes services types. The different subsystems of the server at NA1 would listen for user requests on the designated chat port and notes port.

The first four rows of the illustrative index of Figure 4 contain the network address pattern http://[*]. The [*] symbolizes a universal match. Thus, the pattem http://[*] encompasses every network address that employs the http:// protocol to access information objects over a network such as the Internet. In other words, the pattern http ://[*] encompasses the entire address area of the internet for the http protocol. Assume, for example, that the service area directory server receives an information access device request for an association for the network address of an accessed information object. Furthermore, assume for example, that the network address uses the http protocol. In response to the request, the service area directory server accesses the illustrative service area index of Figure 4 to locate network address patterns that match the subject network address. In this case, there are at least one hundred ninety-nine index entries that match the network address pattern since there are one hundred ninety-nine http://|^"*] entries. This is shown by the fact that the rows with the entry http ://[*] in the first column are correlated with server addresses NA1 through NA199. As explained above, each such entry matches every network address pattern that uses the http protocol. Thus, regardless of the exact network address, there are at least one hundred ninety-nine matches to the subject network address in this example.

As noted above, entry of http://[*] in a row of the index structure of Figure 4 indicates service over the entire Internet for information objects accessed using http. For example, the first four rows of the index structure list ABC Corp. as the service provider.

ABC Corp. sponsors four different community servers located at network addresses NA1 - NA4. The community server at NA1 provides notes and chat for sports enthusiasts. The community server at NA2 provides instant messaging. The community server at NA3 provides notes and chat for automobile enthusiasts. The community server at NA4 provides conferencing services. Moreover, for example, the community server at NA199 sponsored by DEF Corp. provides notes, instant messaging, chat and conferencing services over the entire Internet for http protocol network addresses.

Referring to the example of Figure 4, when an information access device user requests an association to commumty servers associated with any information object addressed with the http protocol, the device user receives from the service area directory server at least one hundred ninety-nine associations corresponding to the http://|^"*] entries. Each association represents a service that is available for an accessed information object network address. The user may pare down service selection based upon the service provider (i.e., the community), the nature of the service (i.e., notes, instant messaging, chat, conferencing, etc.), the subject matter of the communications (i.e., sports, shopping) or whether or not the user is registered to use the service. Thus, network address partitioning can designate set of services provided in overlapping network address areas. Now assume for example, that an information access device user accesses an information object with a network address http://www.xyz. edu/historydept/[*l . Referring to the index structure of Figure 4, the device user would receive an association with the commumty server at network address NA200 sponsored by XYZ University which provides notes service in connection with history. Further, assume that the device user then accesses an information object with a network address http://www.xyz. edu/mathdept/|^"*1. The device user would receive an association with the community server at network address NA201 sponsored by XYZ University which provides notes service in connection with math. Finally, assume that the device user next accesses an information object with a network address http://www.xyz.edu chemistrydept/!*]. The device user would receive an association with the community server at network address NA202 sponsored by XYZ University which provides notes service in connection with chemistry. The partitioning in these three examples might be useful in university sponsored tutorial classes over a network. Thus network address partitioning can be used to provide sets of services that do not overlap in network address space.

In Figure 4, the address patterns http://|^"*l.gov/ and http://[*1.de/ respectively, signify all network addresses is the USA government domain are served by a community server at NA206 and all network addresses in Germany are served by a community server at NA207. It is possible that a service provider may wish to provide service only for communication that occur in context of government information objects. Alternatively, a service provider may wish to provide service only communications in the context of information objects accessed on web sites in Germany to maintain local context, local language and local access for example.

Use of address patterns by a service area directory and community server in the context of a system in accordance with the present invention is shown in Figure 2. Figure

2 shows an information access device 650 accessing in information object 610 at network address NA-x via network 612. Information access device then accesses service area directory server 624, at network address NA-SAD, and provides it with the address NA-x. Service area directory server 624 then searches its index for network address patterns which encompass network address NA-x. As shown by table 626, service area directory

614 includes 51 network address patterns, NAP-1 through NAP-51 (shown in the left-hand column of table 626), which correlate with addresses of community servers (shown in the right-hand column of table 615) and which include network address patterns which encompass NA-x. Because there are 51 community servers which provide services for address patterns which encompass the network address NA-x, if each commumty server was managed by a different provider, then 51 different providers could provide services in the context of information object 610. Additionally, because the services would be provided from separate community servers, the user of a first service from a first community server would preferably not be aware of or interfered with by the user of a second service provided by a second community server.

Next, the addresses, shown in the right-hand column of table 626, of the community servers offering services in the context of information object 610 are returned to information access device 650. The user of information access device 650 then selects the community server at network address NA-3117. This may be either because the user of information access device is not registered with the providers managing the community servers at the other addresses, or because the user of information access device wished to access the type of service offered by the community server at network address NA-3117. As shown table 626, the commumty server at network address NA-3117 provides services for information objects having network addresses encompasses by network address pattern NAP-3. Once information access device has accessed the community server at network address NA-3117, it provides to the community server the network address of the information object being accessed. The community server then searches its index, represented by table 630, for the network address NA-x.

The left-hand column of table 630 includes network addresses of information objects which the community server at address NA-3117 provides services in the context of, specifically information objects at network addresses NA-A through NA-y. The right- hand column shows the service objects, SO-A through SO-y, which are associated with each respective network address. These service objects could, for example, be chat services, notes services, presence services, keyword services or services provided by a third party provider such as videoconferencing. The arrows extending from the right-hand column indicate the information stored in community server at address NA-3117 which is necessary to provide the associated service. For example, if service object SO-A were a presence service, then InfoA, associated therewith, would be a listing of all the other users accessing the information object at NA-A and who had selected to use services provided by the commumty server at address NA-3117. As shown in table 630, the service offered by community server at address NA-3117 in the context of information object 610 is service object SO-x and requires information Infox to operate. Accordingly, the user of information access device 650 will use information object SO-x provided by the community server at address NA-3117 and requiring information Infox to operate.

Scaling

A community service provider may wish to scale the number of community servers allocated to serve device users to meet user demand. In order to achieve this, the community service provider can partition areas of the network (Internet) to reduce the number of information objects, and therefore the number of users, each community server must handle. Partitioning involves separating the space of information objects into unit thereof. What is necessary is to have a "key" with which to refer to the information objects which can be separated into non-overlapping patterns. With respect to the Internet, this is relatively straight-forward. Referring again to Figure 4, the index structure has row entries http://|^"A-H*l, http://[I-P*], and http://[Q-Z*^"|. An information access device request to the service area directory server for an association with any network address pattern using the http protocol that has first following letter beginning in the range A through H (e.g., http://www.albatross.com) will be associated with the entry http:// A-H*1. The information object corresponding to such address, therefore, will be associated with the commumty server at network address NA203, sponsored by GHK Corp., which provides notes service. Similarly, a request for an association with any network address pattern using the http protocol that has first following letter beginning in the range I through P will be associated with the entry http://[I-P*]. Likewise, , a request for an association with any network address pattern using the http protocol that has first following letter beginning in the range Q through Z (e.g., http://www.zipidedoo.com) will be associated with the entry http://[Q-Z*]. The same entity, GHK Corporation provides the same service on three different community servers. One reason might be to balance the load of user device accesses across the servers. Note that from time to time unbeknownst to users, GHK Corporation may change the association of address patterns to community servers. For this reason, the service area index identifies the service provider associated with the commumty server. Thus, a user informed of an association can know the sponsor of the associated community server. This partitioning can be done as finely as necessary to accommodate as many information objects and user as necessary. In this way, the system of the present invention can be scaled to provide as many services as providers desire for as many information objects and users or information access devices as required, up to and including the entire Internet.

Figure 5 shows in greater detail the structure of a service area directory 614. As shown, service area directory 614 includes a master service area directory 190, a backup service area directory 192, and a plurality of service area directory caches 194. Preferably, master service area directory 190, backup service area directory 192 and each service area directory cache 194 are included in a separate computer or server. Backup service area directory 192 is interconnected with master service area directory 190 which is interconnected with each service area directory cache 194. As discussed above, service area directory 614 indexes associations between an address for an information object and the address of a community server which provides services in the context of about the information object. This substantive association information is stored in the master service area directory 190, backup service area directory 192 and each service area directory cache 194. As community servers are brought on line, information regarding the contents and location of the community servers is entered by a system administrator into master service area directory 190. Master service area directory 190 will then update each service area directory cache 194 and backup service area directory 192 with any new information which has been entered. Preferably, service area directory caches 194 are geographically distributed and each client 114 is assigned to a particular service area directory cache 194 which is preferably in a geographic location relatively near the assigned client. Also, preferably, more than one client 114 is assigned to each service area directory cache 194. If one of the service area directory caches 194 goes down, master service area directory 190 can re-assign the clients associated with the down service area directory cache 194. Additionally, if master service area directory 190 goes down for any reason, backup service area directory 192 is preferably able to perform the functions of master service area directory 190 until master service area directory 190 can be brought back on line.

Preferably, as discussed above, service area directory 614 can include any number of hardware servers, that is, it is scalable. Thus, service area directory 614 is advantageously efficiently able to store, manage and retrieve notes, presence, keyword or other types of information associated with any one of the millions of information objects resident on the Internet. Registration and Authentication

Purposes - There are several possible reasons for registration and authentication.

• Gives the service provider assurance that the user really is who they say they are

• which gives service providers the ability to control access to their service • to keep private or confidential information relating to the user

• to assure the user that this information will not be available to other users

• to enable the service provider to conform to the terms of the condition of service agreement

• to integrate easily with their own registration system (if any) • to be able to bill the user for service

• to integrate easily with their existing billing system (if any)

• to enable the provider to control or condition access to the provider's services, e.g., privacy rules, control of who has access to advertising opportunities, user agreement to provide user billing information It is to be understood that it is within the ambit of the present invention that the registration process can occur automatically when a user accesses a community server. It is also to be understood that the registration process, though desirable for a number of reasons detailed below, is not essential to the present invention. Outline of this Section: 1. UserlD - definition

2. Registration - both with Zadu (the manager of the service area directory) and with an individual service provider

3. Zadu Home Servers - a trusted third party

4. Zadu Registration - the details, and the preferred implementation 5. Provider Registration -

6. Cross registration - relating the Zadu Registration with the Provider Registration

7. Authentication - service providers use the trusted third party to authenticate users 8. Performance enhancement

1. User lDs • As used herein, Zadu is the entity which provides the protocol and standards used in implementing a system in accordance with the present invention and could be the manager of such a system.

• The Zadu implementation of the invention defines a globally unique ID for each information access device user

• This means that there is a single namespace for all Zadu IDs that ensures interoperability between users and guarantees no clash of user identification.

• Multiple service providers are supported, each one controlling and managing its own set of (Zadu) communication services, yet each one uses the same Zadu IDs (i.e., the same Zadu namespace).

2. Registration

• With Zadu (the manager of the service area directory) is required to obtain a unique UserlD for the user

• With each service provider is required before the user can access that service provider ' s services

The present embodiment of the invention uses a minimal system for the (Zadu) registration in order to support easy integration with the existing subscription or registration services (including billing, perhaps) of the service provider. The invention allows each service provider to maintain and manage its own set of user information including the type of information and privacy controls and rules. When the provider chooses to offer (community) services, it need only add one extra piece of user information, the unique userlD. This minimal requirement makes integration simple. This is a factor in making a (community) service offering in accordance with the present invention attractive to potential customers and service providers. • Preferred implementation: the service provider has a "cross registration" application, perhaps on a web page, which might offer several facilities, including:

1. Download companion software - perhaps a customized, for example branded version

2. (Zadu) registration - for users who have not already registered with (Zadu) the service area directory manager.

3. Provider registration - for users who have not already registered with a service provider 4. Service registration - the cross registration that relates the Zadu registration with the provider registration

• Thus, a user with no existing registrations will perform all steps.

• An existing Zadu user, who is not yet registered with the provider, will become a new customer.

• An existing customer of the provider, that is a user of some other provider service, becomes a new Zadu user.

• An existing Zadu user, who is also a customer of the provider, gets a new Zadu service to use. The new service is preferably automatically advertised to all existing Zadu users. This can provide a valuable business opportunity for new providers.

Specifically, as any Zadu community grows, new providers can, through this advertising opportunity, leverage off of the commumties created by other providers and vice-versa. 3. Zadu Home Servers • ZHS acts as a trusted third party in the Zadu authentication system

• Each Zadu user is "assigned" to a ZHS which maintains information about the user

• Each Zadu user "registers" with their assigned ZHS to obtain their unique userlD and password

• For day to day operations, the user will use a login to their ZHS using their password

• Preferred implementation: o Uses PKI or digital signatures for authentication o Each ZHS has it's own key-pair, a public key and a secret key o The public key is broadcast widely, especially to all service providers o The secret key is kept securely at the ZHS o The secret key is used to digitally sign (encrypt) the users identification o The public key is used to verify (decrypt) a user's identification o Further details of these operations are given below.

• Scalability of ZHS o A single large computer connected to the network at a well-known address can act as the ZHS for this invention, and using technology available today, a system supporting many millions of users can be easily built. o Preferred implementation:

■ A set of ZHS are used by this invention

■ Each one provides the services mentioned (registration and authentication) for a set of users.

■ Additional ZHS can be added at any time and the load balanced across them.

■ The service area directory can be extended to include in it's index, mappings from userlDs to the network addresses of the corresponding ZHS that provides these services for each range of userlD

In this example, all userlD beginning with 1234 were created at the server with address ZHSl; all userlDs beginning with 1235 were created at ZHS2; and all userlD beginning with 20 were created at ZHS3. They type field of each record separated these entries from the other types of pattern and addresses found in the service area directory.

Note, this index that maps userlD to ZHS addresses, can be a stand-alone index, it is not required to be part of the service area directory. However, it needs to be a scalable index in it's own right, it must be capable of supporting access from millions of users at once, it should be accessible to those millions of users at some well known network address and it must be always available for the service to be reliable. All of these attributes (scalable, high performance, available and reliable) are the same as those desired by other service area directory users, this simple extension of adding a new record type is the preferred solution. As discussed above with respect to Figure 800, a service area directory in accordance with the present invention is scalable. Additionally, because the data contained in the service area directory is replicated in backups and caches, the service area directory is also available and reliable.

4. Zadu registration 1. User obtains and installs companion software on his or her computer

2. Companion software contains the address of the master service area directory (SAD) and contacts it (or the backup SAD if the master is not available). Using the network address of the user's computer and information about the load on the computers running SAD caches, the SAD returns the address of a "local" SAD cache, one that is near (in network terms) to the user, and the companion remembers

(caches) that address.

3. Note: The local SAD address is used for all subsequent SAD accesses. In the event that the local SAD is overloaded or not available, the companion software can still access the master SAD (or backup SAD). In particular, this can be done to re- obtain the address of the local SAD, which is useful for example, if the user computer is moved.

4. Also note: This is the mechanism that ensures the scalability of the SAD architecture. The load can be balanced across as many SAD caches as are required. SAD caches can be brought online and taken offline at will, for addition or replacement or upgrade, with insignificant impact to any Zadu service.

5. Companion software contacts SAD for the location of a Zadu Home Server (ZHS). Using the network address of the user's computer and information about the load on the computers running ZHS, the SAD returns the address of a "local" ZHS, one that is local (in network terms) to the user and the companion remembers (caches) that address.

6. Companion software contacts the ZHS

7. ZHS generates a unique userlD and returns it to the companion o Preferred implementation: base the userlD on the network address of the client and the network address of the server and a sequential number within the server o This technique scales well, it does not depend on any single source for unique numbers

8. At this point the companion software o Knows it's local SAD o Knows it's ZHS o Has a unique UserlD 9. Preferred implementation: o Uses digital signatures o When first run, the companion software generates a key pair, the user's public key and secret key o The user's public key is sent to the ZHS at stage 6 above o The user's secret key is kept securely with the user; it is used to sign (or encrypt) tokens (which can be decrypted only by the corresponding public key). The secret key is usually protected with a password; the secret key can only be accessed when the user gives the correct password. Alternatively, smart cards could be used. o Stage 7 above is extended, ZHS signs the combination of the newly generated userlD together with the user's public key and returns this signed object to the companion software. This object is called the user's passport. It will be used to identify the user. Since it is signed (i.e. encrypted) by the ZHS, it can be decrypted by anyone with the ZHS public key (which has been broadcast widely). 5. Provider Registration a. Usually, the user will be an existing subscriber or customer of the provider, or may register with the provider for some purpose other than gaining access to the community communication tools. Some form of customer identification, a customerlD will be issued at this registration. b. It is likely that the provider will want to collect information about the user over an above what is required to operate the Zadu services, i.e. the community communication tools. Indeed the Zadu service may be just one of many services offered to the user or offered to attract users and customers for the provider. A part of this invention is the ease of integrating the Zadu system with existing provider systems. c. When the user operates the community communication tools, the provider may desire to relate information therein with the registration or subscription information maintained by the provider. For example, as the user accesses different information sources, a recording of the series of network addresses used for access might be used to provide market research data. This recording can be made at the provider's community server, where each network address accessed is available for each userlD. To record this in the user registration database, it is necessary to be able to relate the userlD with the exiting customerlD for that user.

6. Cross Registration a. Cross-registration is the simple process of creating a relationship between the user's userlD and the corresponding customerlD at the service provider. b. The provider will record the userlD of the user in the provider^'s customer database. c. The ZHS will record the customerlD of the user in the ZHS database.

7. Authentication

When a user operates the companion software and it connects to a community communication server, it is essential that the server software can confirm the true identity of the user. Before billing a user or making available their private data, the server software authenticates incoming request for service from the companion software. This is achieved by calling upon a trusted third party to authenticate the user's purported identity.

1. Companion software requests service from the service provider, sends the user's ID together with the request

2. Server software accesses the ZHS corresponding to the users userlD to confirm the identification a. Note: several techniques are available for this type of confirmation b. For example, the server sends a token to the companion who forwards it to its ZHS, the one where the user logged in using their password. The server then checks with the ZHS corresponding with the purported user ID. if the right token is available, then the user is indeed the correct one. c. Preferred implementation: i. Uses digital signatures for added security. ii. Companion sends request for service together with the user's userlD iii. Server responds with a token iv. Companion signs the token with the user's secret key and sends the signed token together with the user's passport to the server. v. Server decrypts the user's passport using the public key from the ZHS (recall: the passport contains the users userlD and the public key.) vi. Server decrypts the signed token using the public key from the passport, which will return the original token only if the public key corresponds to the secret key used to sign the token, vii. Thus, the ZHS has been used as the trusted party that signed the passport originally, viii. Note that as well as being a more secure implementation, this required less communication for the authentication than the simple method described in b. above. 3. The server provides service confident that the user is indeed who they claim to be. 8. Performance Enhancement/Advantages

As discussed above, when determining which community servers offer services in the context of an accessed information object, the information access device queries the service area directory for the addresses of the community servers. The service area directory may list many more addresses of community server which offer services in the context of an accessed information object than the information access device is registered to use. Accordingly, the information access device can filter out these addresses. In this way, there is less information for the information access device to process. This can lower overhead in the information access device and enhance performance.

Additionally, use of a system in accordance with the present invention wherein a unique, global userlD is assigned to each user, as described above, provides a standard protocol under which instant messaging can be used. Use of a unique userlD serves to make IM systems compatible. A central IM interchange server can be provided which can receive a message from an third party IM service which would have either the recipient's unique userlD attached or information from which the interchange server could determine the recipient's userlD. The interchange server could then translate the message from the third party's IM protocol and forward the message to the recipient based on the recipient's userlD.

Moreover, as is made clear by the above discussion, a system in accordance with the present invention creates communities that consist of users who can communicate with one another across a range of information objects, rather than at simply one information object. Thus, a community member can be presented with information or advertisements at each information object included in the community. Provider sponsored information or advertisements can also be included in the communications between community members. For example, a provider could supply information or advertising in annotations which are created by community members. Through use of a system in accordance with the present invention, a provider can gain the attention of a network user over an extended period of time as the user moves from one information object to another within a single (e.g., the provider's) community.

Notification One aspect a present embodiment of the invention is a mechanism for notification.

Notification can be used for several purposes.

There are many benefits that accrue from in-context communication as described both above and below. For example, the ability to leave messages attached to any information object on the entire network where they can be seen and addressed by other members of the community, in context of the underlying object

• Saves referring to the object in an out-of-context communication

• Makes it easier for the other users to understand the commumcation, because it is in-context

• Opens up the opportunity to communicate with as yet, unknown users • Creates the opportunity for the community owner to manager or moderate the communication

• Community owners may develop more detailed and valuable profiles of users based on their communications

Obviously, to support such on-context commumcations across a large-scale network requires a scalable system, which is one object of the present invention.

However, as mentioned in the background section, for the user there is potential problem with such diverse communications, specifically, how can a user keep track of them? With email, for example, where a sequence of messages can be exchanged between users, they all show up in the same place - a different problem is created, how to separate this discussion from all of the other email messages. With messages scattered all over the network, and without some form of notification, the user would have to make frequent accesses to each discussion context to check for replies.

One aspect of the present invention involves a mechanism to notify users (if they require) when replies are made to their (in-context) messages. Thus a user is saved the time of repeated, wasteful checks.

Instant messages, chat and videoconferences are all examples of synchronous communication where on-line users are notified of incoming messages or request to chat or an invitation to join a conference. Such notification is a natural part of synchronous communication. This invention defines an expanded information access device that connects to the community service network in addition to its basic functions. This device connects to the home server to facilitate notification. The user logs-in to the home server using their password and a connection is maintained with that server. The fact that the user is on-line is recorded as part of the user's status and is available for others to inquire upon. All other component parts of the community communication system are able to access the user's status and also to send a notification message to this user knowing only the unique userlD of that user. As described above, the service area directory includes an index that relates any given userlD to the corresponding home server. Messages and notifications sent to the user who is off-line are stored at the home server and made available to the user the next time they login. A "buddy list" or "contact list" of known friends or contacts can be maintained at the information access device, when logging-in the on-line status of each of these is accessed and presented to the user. Changes to this status are also sent to the user's buddy list, thus notifying them of the on-line status of their contacts.

A novel form of notification comes from the "presence" mechanism that is part of this invention. The presence mechanism allows one or more users who access the same information object to become aware of each other's "presence at that object" which can lead to possible in-context (synchronous) communication. This mechanism is extended to give notification when a user first "arrives" at the information object. Examples of use of this can include an on-line receptionist at the home page of a company's web site, a doorbell at a user's home page on the world wide web, a shopping assistant at an e- commerce site, a customer service representative or an entertainment guide.

One computer program implemented process for implementing notification is a s follows: Notification mechanism

• User logs-in to their home server and maintains a connection with it.

• Messages and notifications may be already queued at the home server, if so these are retrieved by the information access device and presented to the user. • User's on-line status is sent to all users on the buddy list

• Messages and Notifications targeted at a user can be sent using the user's unique userlD

• Any component of the community commumcation system can use the service area directory to locate the user's home server given their userlD • Messages and Notifications are sent to the home server and forwarded to the user's information access device for immediate display while they are on-line. Typically this takes the form of flashing an icon on a toolbar and/or making a sound, usually at the user's choice.

• When the user logs-off and breaks the connection with their home server, notification is sent to all users on the buddy list, i.e. the home server sends the notification to the home server of each of the users listed on the buddy list.

Notification of posting

• When making an annotation or replying to a note, the user may specify that a notification should be sent when a reply is posted. The user's unique userlD is recorded as the author of that note.

• When a user replies to a note, the author's userlD and request for notification are available and can be used to send the notification (using the service area directory and home server as described above).

• In this case, the notification includes the network address of both the note itself and the underlying information object, making it easy for the user to re-access the object and the reply to their note.

Notification of messages

• There are two distinct ways to initiate synchronous communication such as sending an instant message or chat request or invitation to a conference 1. Using on-line presence

2. Using the buddy list • 1. Another user's on-line presence can be seen when accessing the same information object or as the author of a note or in other contexts. In all such cases, the on-line status of the other user is presented as part of the user's access to the information object or the note. Synchronous communication can be initiated directly by the user selecting the other user's icon and choosing from a menu of communication functions.

• 2. The on-line presence of the known users in the buddy list is always available and is made visible in the display of the buddy list. Selecting the appropriate icon in the buddy list and choosing from the same menu of communication functions is all that is required to initiate communication.

• As described elsewhere in this document, these forms of synchronous communication may be established directly from client to client machine (when the user information contains sufficient data to allow this, for instance the user's IP address) or may be established through a server, in case 1) through the community presence server and case 2) through the user's home server.

Notification of Presence

• User selects an information object that they want to monitor and sends the network address of it to the chosen community presence server together with a notification request. (The URL doorbell) • When another user accesses the same information (and has the same community presence service enabled) the usual operation of the community server will send information about this other user to the "monitoring" user^'s access device, which by virtue of the pending notification request (the URL doorbell) will cause a notification to be presented to that user.

Network Area Based Associations of Users by Community Servers

Zadu Service Provider - General Model

Each (Zadu) Service Provider implements its commumty communication services as a set of software systems (servers) running on a computer(s) in the network. Service is provide "in context" of particular information objects that the user might access over the network. The address of each server is stored in the Service Area Directory (SAD) indexed by the network address pattern of the information object, thus each server is associated with areas of the network address space. Client software uses the SAD to find the address of all servers that offer service in context of a particular information source.

When a client computer makes a network connection to a particular server, the network address of the information object is provided with the request for service. The server maintains a table that relates network addresses to service objects. There is an entry in the table for each information object that is "in use" i.e. has some community communication under way, in context of the object itself.

As shown in Figure 6, which is a simplified illustrative drawing of this process, a new network address 910 is "matched" (compared) with the table 912 of network addresses, and if there is a match, the corresponding service object is returned to the client software, thus allowing it to join with the existing communication. This process is illustrated in Figure 6 which shows a table

For example, a service that provides annotations in context of information objects would have an entry in this index for each object that is currently annotated. The service object would be a list of anchors or markers of where the annotations lay together with information about the annotations themselves so the user can access them as required. When a user accesses an information object that already carries annotations, this service will access the annotations. (It should be noted of course, that preferably, the information object itself does not carry the annotations; the annotation system gives the appearance of that by superimposing the object and annotation visualizations. The annotations are actually stored at an annotation server, indexed by the same network address as the information object.) As discussed above, the service area directory can hold as many network addresses, and network address patterns as necessary, and there can be as many community servers as necessary. Thus, this annotation service is scalable and able to include the entire Internet. Further, because different community servers can service the same information object or range of information objects, as many annotations services as necessary can be provided for a single information object or range of information objects.

The user's software (e.g., browser) will access the information object, and the (Zadu) companion software will accesses this service passing into the SAD the same network address that was accessed by the user software. The network address of the object will match one or more of the rows in the index, the server software will return the corresponding service object(s) containing the anchors to the companion software for display. Structured Network Addresses

Objects accessible via networks have Network Addresses that have an inherent structure comprising a number of components that have more or less significance with respect to the location of the object. For example, the network address of my inventory document might be:

"\\My-computer\C-drive\My-directory\inventory-document" In this example, the components are separated by \ characters and are listed with the most significant component on the left and least significant on the right. Dropping the least significant component would leave: "\\My-computer\C-drive\My-directory"

This is the network address of the directory that might contain several documents that are "close" or related to each other, if only because they are all stored on the same disk and in the same area, in this case, directory on that disk.

Of course, this example shows the network address relative to some local area network, a more complete address would include more information about location, such as the company or organization where My-computer is installed, and the country or domain of the company. For example: http://My-computer.XYZ.co.uk/C-drive My-directory/inventory-document In this form of network address (actually a URL), the components of the address include an access protocol (http:), the computer address (my-computer .XYZ.co.uk) and the document address (/C-drive/My-directory/inventory-document) within the computer. With the computer address, components are listed with the least significant on the left, the most significant on the right and they are separated by '.'

My-computer identifies a particular computer installed at . XYZ.co XYZ, the name of the company, which is

. uk based in the UK

Network Address Matching - Exact and Area based

As described above. Zadu servers match (compare) incoming network addresses to the list of addresses stored in the index. This match can be performed in two ways, (1) an EXACT match where the addresses must match all of their components, thus identifying an existing service object related to the specific information object address or (2) and AREA match, where only the more significant components of the addresses match, thus identifying an existing service object related to an information object that is in the same area, or local to the incoming object address.

When matching and incoming network address with the addresses in each row of the index: • EXACT match - all components of the incoming address must match. o When one or more rows match, the corresponding service object(s) are returned. o If no rows match, the server may:

^■ Return a null result to the client ■ Optionally, the server may create a new row, with the address set equal to the incoming address, an empty service object is created and returned to the client • AREA match - the server may choose to match one or more significant components of an incoming address. Exact matches are used by servers that offer their service "in context" of a specific information object.

Examples include, annotations superimposed on an object, a chat room instantiated on an object.

Area matches are used by server that offer their service "in the area nearby" a specific object. Examples include, meeting users who are access objects in the same area, showing the presence of other users browsing web pages in the same domain. Area Based Meeting Service (ABMS)

The Zadu ABMS server implements a service where users can meet in an area or where their presence can be seen by other users who are access the same area of the network address space.

In other words, the context in which users can be co-present is Scaleable. They may be co-present in a larger or a smaller "address area" or "context". In the present embodiment the context area varies with the number of users co-present in the area at any time. Of course other criteria for scaling the shared context area also may be employed consistent with the invention.

• ABMS uses AREA based matching

• ABMS service objects are a list of user IDs present in that area. ABMS implements a dynamic AREA matching algorithm, the number of components of network address that are used to match with the addresses in the index is varied according to the following rules. These rules create the effect of expanding the size of the address area when there are only a few users "present" (in or near the address area) and decreasing the size of the area when there are many users "present" (in or near the address area). This makes the meeting service much more useful and practical than exiting systems where the areas are fixed.

• ABMS has two thresholds o LONELY, set for example to 4 o BUSY, set for example to 25

• When the number of users in an area is < LONELY, change the match to increase the size of the area, this will increase the chances of meeting someone who is accessing information close to yours.

• When the number of users in an area is > BUSY, change the match to reduce the size of the area and create a new service object for each (smaller) area, this will reduce clutter and increase the chance of meeting someone who is accessing information closer to yours. Client Arrival

1. Client initiates access to some information object 2. Client uses the routine Zadu processes to ascertain the address of the ABMS server that is offering meeting services in context of that information

3. The network address of the information is sent to the ABMS server

4. ABMS server matches the incoming address with the index table

5. If nothing matches, the area is increased until a match is found 6. If the service object indicates > BUSY people in the area, then change the match to reduce the area size and a new service object is created.

7. Server adds this user's ID to the service object

8. Finally, a new entry for this user is made, with the incoming address and the same service object. Client Departure

1. When the user ceases access to the information, client sends a 'remove' message to the server 2. Server removes the user's ID from the service object (see 8 above)

3. If the number of users is < LONELY then the service object is consolidated with surrounding objects until the number of users >= LONELY

4. Server removes the entry made in step 8.

It will be understood that the foregoing description and drawings of preferred embodiment in accordance with the present invention are merely illustrative of the principles of this invention, and that various modifications can be made by those skilled in the art without departing from the scope and spirit of the invention.

Claims

1. A communication system operative in a computer network together with an information retrieval system that retrieves information over the network and in which information to be retrieved is associated with network names that can be resolved into network addresses used to locate information to be retrieved on the network, the communication system comprising: a plurality of respective community servers resident in computer storage media accessible over the network, the respective community servers providing communication over the network among respective computers that use such respective community servers; a network name association structure resident in computer storage media accessible over the network, the network name association structure associating respective network names with respective community communication processes; and at least one instance of a network name receiving structure resident in computer storage media of at least one given computer accessible over the network, the network name receiving process receiving respective network names associated with information to be retrieved by the given computer in the network and informing the network name association structure of respective received network names.