WO2003030024A1

WO2003030024A1 - Information systems

Info

Publication number: WO2003030024A1
Application number: PCT/GB2002/004409
Authority: WO
Inventors: Fang Wang
Original assignee: British Telecommunications Public Limited Company
Priority date: 2001-09-28
Filing date: 2002-09-27
Publication date: 2003-04-10

Abstract

One embodiment of this invention relates to an information system comprising: means operable to establish a plurality of search entities (54) each operable to instigate a search of said information system; and means operable to establish a plurality of management entities (52), each including a register (56) for recording the identity (57) of one or more of said plurality of search entities (54) and information (59) pertaining to information resources of said one or more search entities (59), said management entities (52) being operable to process said searches; wherein said management entities (52) are operable to group said search entities (54) in search entity communities that are each registered with at least one management entity (52) on the basis of the results of said searches.

Description

INFORMATION SYSTEMS

This invention relates to information systems, and in the preferred embodiment to distributed information systems arranged to manage information on behalf of users.

BACKGROUND TO THE INVENTION

Any distributed information system is likely to involve a large number of active users who will include within their ranks: information providers, information consumers, and users who both consume and provide information. To improve the manner in which these users interact with the system (and with one another), it has previously been proposed to use "middle agents" to facilitate the provision of services. Generally speaking, middle agents are software agents that act as intermediaries between the users and the resources that they might wish to access, and between individual users. The services provided by middle agents might include, for example, checking that a particular item of information is available, searching resources in response to user requests, providing useful information held by other users to a user or users, or broadcasting information to certain interested users.

A key problem for these information systems is how to organise users and the middle agents so that the users can receive appropriate services quickly and efficiently.

To alleviate this problem it has previously been proposed to adopt a centralised architecture where every user has a connection with a single middle agent. Typical centralised systems are described in the following articles: • "Matchmaking for information agents" by D Kuokka and L Harada, published in Proceedings of IJCAI'95, pp. 672-678, Montreal, Canada, 1995;

• "A communication infrastructure for concurrent engineering" by D Kuokka and L Harada, published in Artificial Intelligence in Engineering, Design, Analysis and Manufacturing, 1 995; • "Infosleuth: Agent-based semantic integration of information in open and dynamic environments" by RJ Bayardo Jr, W Bohrer, R Brice et al, published in Proceedings of ACM SIGMOD-97, 1 997; and

• "Matchmaking to support intelligent agents for portfolio management" by M. Paolucci, 2. Niu, K. Sycara et al, published in Proceedings of A AAV 99, 1 999. Whilst centralised systems such as these do tend to facilitate the locating of information resources for users, they are generally not suitable for a large number of users due to the fact that the workload of the middle agent can easily be overloaded (by, for example, a large number of users requesting services at the same time). Centralised systems are also vulnerable to failures because of the fact that the whole system will come to a halt if the middle agent fails to work properly.

As an alternative to a centralised architecture it has been proposed to employ distributed middle agents to mediate between users and the system as a whole. Examples of such systems are the IDIoMS system (which employs Open

Agent Middleware (OAM)) and Abrose. Details of the IDIoMS and Abrose systems can be found in the following documents:

• "Virtual Integration of Distributed Database by Multiple Agents" by T. Mohri and Y. Takada, published in Proc. of the First International Conference - Discovery Science (DS'98), LNAI 1 532, pp. 41 3-414, 1998;

• "Multi-agent System for Virtually Integrating Distributed Databases" by Y. Takada, T. Mohri and H. Fujii, published in FUJITSU Sci. Tech. Journal, Vol. 34, No. 2, pages 245-255, December 1 998; and

• "Abrose: a cooperative multi-agent based framework for electronic marketplace" by H. J. Einsiedler and A. Leger, published in Lecture Notes in

Artificial Intelligence v1699, 1999.

In the Abrose system, for example, users can maintain a network of their preferred neighbourhood by enhancing or decreasing their beliefs to others, but this networking can only happen in a local area controlled by the same middle agent. A further problem is that as the allocation of a user to a middle agent is a priori, the system does not suit dynamically changing environments in which information and users are frequently changing.

More importantly, since user preferences or interests are not taken into consideration when organising users, it is often the case that the route between a given user and a desired resource can be quite tortuous and can require the participation of a number of middle agents. These tortuous routes mean that there is often quite a considerable delay between finding a resource and supplying it to a requester. As a consequence of this architecture, these systems rapidly become very unwieldy if the information held by users or other resources is very distributed.

To help avoid these problems it has previously been proposed to group users with similar preferences. Once instance of this is the so-called

"recommender system", for example the system described in "Recommender Systems" by P. Resnick and H.R. Varian, and published in Communications of

ACM, V40, No. 3, 1 997, pp 56-58.

One approach to implementing a workable recommender system is to carefully design similarity calculation methods (i.e. algorithms) a priori, and then use these to create groups of users with similar preferences - the theory being that users with similar interests will more likely be able to quickly answer queries posted by other users in their group.

However, recommender systems have often proved to be problematic because the relationship between users in such systems is always predefined by the matching method employed. As a result, addition of new users or changes to existing user preferences can involve a significant amount of recalculation, and reallocation of users, by the human system designer. This drawback means that such systems are not well suited to a dynamic environment where the users and/or their preferences are likely to be subject to change.

Another problem associated with these recommender systems is that it is not easy to design suitable matching methods, and as a consequence the resulting user groups inevitably include some users with mismatched preferences. STATEMENT OF INVENTION

According to one aspect of the present invention there is provided grouping apparatus for grouping users together, wherein each user is represented by an entity (54) that is operable to perform certain tasks on behalf of the user, and each entity is associated with one of a plurality of groups; the apparatus comprising a store (56) arranged to store data (57, 59) in respect of a plurality of such entities, the data identifying one or more characteristics of the users represented thereby identifying means (104, 1 10, 1 1 2) arranged to receive input from such an entity and to identify stored data that matches the received input, the identifying means being operable to identify an entity associated with the identified data assigning means (1 22, 1 26) arranged to assign a value to an entity, the value being indicative of the degree of success of said identification of data grouping means ( 1 28, 1 30) arranged to group entities together on the basis of their respective assigned values the apparatus being arranged, in use, such that in response to receipt of input from an originating entity, the identifying means identifies data, from the store, that matches the received input, and in the event that the identifying means successfully identifies such matching data, the assigning means increases both the value associated with the originating entity and the value associated with entity corresponding to the identified data, whereupon the grouping means compares the respective values, and, if there is a difference between the values, groups the entity having the lower value with the group associated with the other entity, thereby grouping users associated with the said entities together. An advantage of moving the entities having lower values towards the entities with higher values is that entities can automatically be grouped according to their interests, so that those entities who have generally been less successful in their quest for information (i.e. the entities with lower values) are associated with those who have been more successful in their provision of, or quest for, information (i.e. the entities with higher values) .

The comparison between values is effected in respect of entities that have responded to and/or provided the input, so that the comparison of values, and thus movement of entities, is not performed in an indiscriminate manner.

Preferably identifying means and storage are distributed so that there is one identifying means and one store associated with each group. If, in such an arrangement, an entity inputs a request for information to its group, the identifying means associated therewith tries to find data that matches the request in the store associated with the group. If no such data can be found, the identifying means forwards the request to an identifying means associated with another group; such forwarding occurs a specified number of times. Clearly, if entities that have similar data are associated with the same group, the amount of searching, and thus loading on the system is reduced, since there is no need to forward the search to another identifying means. Thus grouping of entities according to the invention is particularly beneficial when the identifying means and storage are distributed in the afore-mentioned manner.

Other preferred embodiments and features of those embodiments are set out in the dependent claims. BRIEF DESCRIPTION OF THE DRAWINGS

One embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Fig. 1 is a schematic view of components of a multi-agent information system with which the present invention can be used; Fig. 2 is a schematic representation of elements of a network of computing resources;

Figure 3 is a schematic representation of elements of one of the computing resources of Figure 2;

Figure 4 is a block diagram illustrating programs present in memory of the computing resource of Figure 3;

Fig. 5 is an illustrative representation of a system maintained by the network of Fig. 2;

Fig. 6 illustrates the steps of a User Infohabitant creation process;

Fig. 7 is a flow diagram illustrating the functionality of an illustrative User Infohabitant;

Fig. 8 is a flow diagram illustrating a re-registration (or exchange) process;

Fig. 9 is a flow diagram illustrating the functionality of an illustrative Middleman Infohabitant;

Figs. 10a, 10b, and 10c are schematic representations of a search for information, a reward of information requester and provider, and a subsequent exchange of User Infohabitants between two Middleman Infohabitants; and

Fig. 1 1 is a screen shot of an experimental system maintained by a network of computing resources.

SOFTWARE INFRASTRUCTURE An embodiment of the present invention can be implemented with a multi- agent software platform such as, for example, the DIET software platform described in the following co-pending patent applications: European Patent Application No. 01 301 885.8, United Kingdom Patent Application No. 01 06957.4 and European Patent Application No. 01302606.7 filed on 1 March, 20 March and 21 March 2001 respectively - the contents of which are incorporated herein by reference.

An "agent", as referred to herein, comprises lines of software code (and usually associated data) that define a software entity, effectively a computer program, which is to some extent autonomous.

The DIET acronym stands for Decentralised Information Ecosystems Technologies, and the system has been described in general terms in the following paper: "Agents in Decentralised Information Ecosystems: The DIET Approach" which was presented at the Artificial Intelligence and Simulation of Behaviour conference, and published in the AISB Symposium on Information Agents for Electronic Commerce 2001 (see pages 109-1 1 7). Pertinent details of the DIET system are described in Appendix A of the current specification. HARDWARE ARCHITECTURE

The DIET platform has been designed to be of particular use in distributed computing systems. By their very nature, distributed computing systems will typically involve a large collection of computing resources and it is likely that they will all be quite different from one another. However, in its simplest form the hardware required for implementation of the DIET platform comprises a plurality of computing resources which are capable of running Java and the bespoke DIET software, and which are capable of communicating with one another.

Fig. 2 is a schematic representation of a plurality of computing resources 1 6 that are capable of communicating with one another via, in this particular arrangement, an Internet 18. This particular arrangement has been chosen for simplicity, but it will be apparent that as an alternative, or as an addition, to an Internet, some or all of the computing resources 1 6 could be connected to one another by means of an Intranet, a LAN or WAN, peer-to-peer connections or by any other means.

Fig. 3 is a schematic representation of an illustrative computing resource

1 6. The resource 1 6 comprises a central processing unit (CPU), a memory 21 , storage 22, a visual display unit (VDU) 24, a keyboard 26, and a communications port 28, coupled to communications channel 30 (such as an ISDN link). These elements are interconnected via a conventional bus structure (not shown).

Referring to Fig. 4, a plurality of control programs are stored in storage 22 for execution. As shown, these comprise an operating system 32, such as Windows ME or Windows NT, a communications protocol stack 34 such as TCP/IP, a Java Virtual Machine 36, and the above described DIET platform 38. The Java Virtual Machine 36 and DIET platform 38 collectively comprise an operating environment (labelled collectively as 40) for the grouping apparatus of the invention.

In the particular arrangement shown in Fig. 2, a web server 20 is provided to which users can connect by entering the URL of a web page maintained by the server into their respective operating environments 40 (which might include a web browser). Once connected to the server, users can (by manipulating the GUI), for example, download Java applets as required for local execution. At the server end of the system, the web server 20 comprises a store for the applets and software for retrieving and distributing applets in response to requests from users. LAYERED ARCHITECTURE

Referring to Fig. 1 , the DIET platform architecture has three layers, a core layer 10, an Application Reusable Component (ARC) layer 1 2 and an application layer 14.

The core layer 1 0 includes the fundamental functionality available to all entities of the DIET architecture; this functionality is embodied in a "DIET Kernel" which is a set of Java classes. It will be understood that a "Class" is a basic concept in object-oriented programming. A class is an object-oriented module that describes the implementation of a "type" of object, including the categories of data associated with objects of that type. Every object is an instance of a specific class and different objects of the same class differ in their data content. In a DIET platform for running an application, the DIET kernel will be used to provide objects of various Java classes including: World; Environment; and Infohabitants (other classes are described in the aforementioned pending applications) .

The agents themselves (known as Infohabitants) are in the ARC and application layers 1 2, 14. The ARC layer 1 2 includes optional components that are useful to various applications. These may be Infohabitants or Listeners (further details of which are set out in the aforementioned co-pending applications). The application layer 14 contains application-specific code that is loaded as processes in Infohabitants.

Generally speaking, an Infohabitant can be described as a computer program which is capable of communicating with another computer program. As a basic minimum, it is provided with means for communicating with other Infohabitants. It will also usually be provided with software code for performing one or more series of operations in use. When an application runs using the DIET platform, Infohabitants in the ARC and application layers 1 2, 14 will execute their code as necessary. In executing their code, they will need to communicate with their environment and, via the environment, with other Infohabitants. For example, the Infohabitants need to communicate with the environment in order to be allocated threads in order to run their code. They also need to communicate with other Infohabitants to exchange data messages. The other Infohabitants might also be in the application layer 14, or they may supply application re-usable services and thus be in the ARC layer 1 2. As far as the Infohabitant is concerned, for these communications to occur, there are a limited number of events that will happen in support for which it will require a thread in order to respond.

Every Infohabitant has an identity, known as Infohabitant ID, consisting of a binary Name Tag and a binary Family Tag. The Name Tag allows Infohabitants to be uniquely identified, and the Family Tag can be used to identify groups of Infohabitants, for example groups of Infohabitants which share similar functionality. The Name Tag can be used to identify Infohabitants and is randomly initialised by the DIET kernel when the Infohabitant is created. Provided the Name Tags are sufficiently long, the probability that two Infohabitants have equal names is effectively zero. For example, when tags are 1 28 bits long, the probability that two or more Infohabitants in a group of one million have the same name is 1 .5 x 10^"26. The advantage of this approach is that it is decentralised and thus scales well. Family tags can be used as a shared identifier for a group of agents, or as an identifier which can be set according to an agreed rule, or as an evolved identifier which externally distinguishes a specific sub-species of adaptive agent. OVERVIEW OF PREFERRED EMBODIMENT Referring to Figure 5, grouping apparatus according to an embodiment of the invention is generally referred to as a grouping system 50. In this embodiment, the groups are administered by so-called Middlemen agents 52 (which are "Middlemen" type Infohabitants). Each Middleman agent has a store (register 56), identifying means (104, 1 10, 1 1 2), grouping (1 22, 1 26) and assigning (1 28, 1 30) means configured to perform the functions described in claim 1 . Within the system there is a plurality of User Infohabitants 54, which are organised into groups or communities (as will later be described) associated with one or more Middleman Infohabitants. Advantages of this arrangement include scalability, since the system is scalable for a large numbers of users; and self- adjustment of system parameters - user agents tend to be organised away from unpopular middle agents, with the effect that unpopular middle agents can lose all user agents and become redundant. As a result, the system tends to adapt to an optimum number of middle agents.

The interaction between these Middlemen and User Infohabitants 52, 54 will be described in general terms, followed by a detailed description of an embodiment of the invention. User Infohabitants 54

Each user (where a "user" is either human or another piece of software) is associated with a User Infohabitant (i.e. a software agent representing that user) and the user can use their agent to interrogate the information resources of the grouping system, and retrieve information therefrom. Every User Infohabitant registers with at least one randomly selected Middleman Infohabitant before it seeks services from the system, so that the Middleman Infohabitant with which they have registered is aware of the information resources held by that user. The registration information may include summarised information of the information resources held by the user. For example, if the user's information resource comprises documents, then the summarised information might comprise titles, authors, or keywords for each of those documents. Once registered with a

Middleman, User Infohabitants can be un-registered with that middleman and reregistered with another Middleman.

In the preferred embodiment, all information in the system is owned by the user agents, but as will later be explained this need not be the case. Similarly, whilst in the preferred embodiment each user stores the items of information that they own, the items of information could all be stored at a central repository (for example at the web server 20 shown in Fig. 2).

Middleman Infohabitants 52

Middleman Infohabitants are middle agents in the system and act as intermediaries between users agents. In general terms, the Middleman Infohabitants are responsible for managing User Infohabitants and for providing services for them. The main activities of a Middleman Infohabitant include: registering/un-registering User Infohabitants, receiving queries from User Infohabitants or other Middlemen Infohabitants, searching for suitable answers to user or Middleman queries, sending answers to User Infohabitants in response to a query, evaluating user behaviour, and exchanging User Infohabitants with other Middlemen Infohabitants.

As will now be described, searching for answers to User queries is accomplished via a Search Scheme, evaluation of user behaviour is accomplished via an Award Scheme, and exchange of User Infohabitants is accomplished via an Exchange Scheme.

Search Scheme

In the preferred embodiment every Middleman Infohabitant has a database which records the information held by the User agents registered with it (other alternatives will later be described). When a Middleman agent receives a query message (i.e. a request for information) from a User Infohabitant assigned to that Middleman, the Middleman first checks its own database to see if the information requested is locally available from one of the other User Infohabitants registered with that Middleman. If the information requested is available locally, the Middleman can send it directly to the requester or arrange for it to be sent to the requester.

If the information is not available locally, the Middleman can seek assistance from other Middleman Infohabitants. If those other Middleman Infohabitants have information in answer to the query, then that information can be passed onto the requester and the search has been successfully concluded. If, on the other hand, no answer can be found after several attempts to get it from neighbouring Middleman Infohabitants, the Middleman stops searching and declares that the search has failed.

When a Middleman Infohabitant receives a query message from another Middleman, it searches in its own database for this query. The results of the search, irrespective of whether or not they are useful, are sent back to the requesting Middleman. A ward Scheme

In general terms, the award scheme is a mechanism that allows the grouping system to differentiate between users who contribute to the system, and users who abuse or are of no use to the system.

When a Middleman relays search results to a User Infohabitant, it examines the search results to determine whether the search has been successful. If the search has been successful (i.e. if the search result is not empty), both the User Infohabitant that requested the information and the User Infohabitant that provided the information are awarded a positive mark. If the search fails, then the requesting User Infohabitant is given a penalty for the extra load it put on the system.

By means of the award scheme, it is possible for Middleman agents to recognise those User agents who are contributing to their community or to the system as a whole, and those who are not. This information plays a role in the formation of user communities where Users with like interests are grouped together in discrete groups within the system. Exchange Scheme If a search conducted by a Middleman on behalf of one of its User

Infohabitants is finished successfully, the Mid^rdleman then determines whether the requester User Infohabitant and the provider User Infohabitant are both in its group or community.

If they are not in the same community, the Middleman for the requester User Infohabitant negotiates with the Middleman for the provider User Infohabitant for an exchange so that both requester User Infohabitant and provider User Infohabitant are registered in the same community.

During exchange, user agents with lower awards move towards user agents with higher awards, and in the process move from one community to another. Since user agents with high awards have either requested or provided useful information to other user agents, moving agents with lower awards towards them results in the formation of communities with user agents that have similar preferences or interests.

By using the Search, Award, and Exchange schemes, middle agents (Middlemen) can provide useful services for users, and also recognise and group users with similar interests. Advantageously, the Middlemen do not need to know what information is held by each user agent to group them according to their interests as the recognition is based on search results, i.e. the behaviour exhibited by user agents. As a result, any grouping imposed by the system is not constrained to particular information or user preferences, and this means that the grouping of user agents can follow user preferences more precisely. It has been noted that by adopting a grouping that is based on user agent behaviour it is possible to generate communities that accurately reflect the interests of the users, whilst avoiding the difficult user similarity calculations that characterise some of the prior art systems. Another advantage of the system of the invention is that it is readily adaptable to all types of information and users. Another advantage of the system is that it simplifies the broadcast of messages to groups of users with common interests. DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

Fig. 5 is an illustrative representation of a grouping system 50 maintained by the web server of Fig. 2 and the operating environments of computing resources connected thereto.

Within the system 50 there are provided a number of Middleman infohabitants 52 (identified as "M.MAN (i)" to "M.MAN(iii)") each having a discrete Name Tag 53. Each of the Middleman Infohabitants 52 has a number of User Infohabitants 54 (identified as "U.AGENT(i)" to "U .AGENT(xii)") registered with them. Each of the Middleman Infohabitants has a register 56 in which is recorded the name tags 57 of each of the User Infohabitants 54 registered with a given Middleman Infohabitant 52, and information 59 identifying the resources held by those registered User Infohabitants.

Each User Infohabitant 54 also includes an Award register 58 that indicates the number of awards assigned to each Infohabitant. On creation, the Award register of each Infohabitant is set to zero. As is also shown in Fig. 5, each User Infohabitant 54 adopts as its Family Tag 55 the Name Tag 53 of the Middleman

52 with whom they are currently registered.

Creation of User Infohabitants

Fig. 6 illustrates the steps of a User Infohabitant creation process 60. As shown, the first step 62 is for a user equipped with the appropriate software to connect, in this embodiment, to the system that it maintained in part by the web server 20. In the next step 64 the User indicates, for example by clicking on an appropriate button in the GUI of their operating environment, that they wish to create a new User Infohabitant.

The system accesses a stored new-lnfohabitant applet and, in step 66, the DIET kernel randomly generates a bitstring as a Name Tag for the new Infohabitant. The user is then prompted in step 68 to enter identifying information (such as - for documentary resources - titles, authors or the like) for each of the information resources they own. Once the user has entered the information identifying the information resources that they own, a new User Infohabitant is retrieved from storage associated with the web server, and is assigned (in step 70) the randomly generated bitstring as the name tag of its Infohabitantidentity.

Once the new Infohabitant has been assigned a name it is randomly allocated, in step 72, to one of the middleman Infohabitants 52(i) to 52(v) resident in the system 50. In step 74 information identifying the information resources (in this case documents) held by the user is recorded along with the name tag of the new User Infohabitant in a register 56(i) to 56(v) of the Middleman Infohabitant with which the User Infohabitant is registered, and the name tag of the Middleman Infohabitant is imported to the Family Tag of the User Infohabitantidentity (step 76) to indicate to the system that this newly created User Infohabitant is associated with the Middleman Infohabitant with which it is registered, and forms part of the community associated with that Middleman Infohabitant. Detailed Description of the User Infohabitant Fig. 7 is a flow diagram illustrating the functionality of an illustrative User Infohabitant. As shown in Fig. 7 the User Infohabitant is normally in a dormant state cycling between incoming message detection code 80 and User query detection code 82. In the absence of either an incoming message or a user query the User Infohabitant will continue to cycle in this dormant state indefinitely.

If the user query detection code 82 should determine that a user query has been entered, for example by means of the GUI which forms part of the aforementioned operating environment, then the User Infohabitant invokes code 84 to forward the inputted query to the middleman with which the User Infohabitant is registered. Once the inputted query has been forwarded to the Middleman, the Infohabitant returns to its dormant state cycling between the incoming message and user query detection code 80, 82.

If the incoming message detection code 80 should determine that the middleman with which the User Infohabitant is registered has sent a message to the User Infohabitant, then the User Infohabitant invokes code 86 to determine whether or not the message sent is an instruction to re-register with another middleman.

If the message is an instruction to rβ-register with another middleman, then the User Infohabitant invokes re-registration code 88 to un-register from its current Middleman and subsequently re-register with the Middleman referred to in the message. The message may take the form, for example, of a set of instructions and data identifying the Name Tag of the Middleman with which the User Infohabitant is to be registered. Fig. 8 is a flow diagram illustrating the functionality of the re-registration code 88. Once the User Infohabitant has been re-registered with the new Middleman, it reverts to its dormant state cycling between the incoming message and user query detection code 80, 82.

If the message is not an instruction to re-register with a new Middleman, then the User Infohabitant invokes query result message detection code 90 to determine whether or not the incoming message from the Middleman with which it is registered comprises the results of an earlier user query. If the message does comprise the results of an earlier query, then the User Infohabitant invokes result processing code 92 to process the results message received. Once the result message has been processed, the User Infohabitant reverts to its dormant state cycling between the incoming message and user query detection code 80, 82.

If the User Infohabitant determines that the incoming message from the Middleman with which it is registered does not comprise the results of an earlier user query, then the User Infohabitant assumes that the message has been sent in error and ignores it. The User Infohabitant then reverts to its dormant state cycling between the incoming message and user query detection code 80, 82.

A User Infohabitant may solely act as a source of information and not actually issue a query on behalf of its associated user. For such a User Infohabitant, information stored in the register 56 of its corresponding Middleman Infohabitant is only ever accessed by a Middleman in response to a query; it is never used to formulate a query. In other words this User Infohabitant only ever acts as a providing User Infohabitant. User Infohabitant Re-Registration

With reference to Fig. 8, in the first step 90 of this process the User Infohabitant - upon receipt of a change middleman instruction (described later) - instructs the Middleman Infohabitant to copy the User Infohabitant Name Tag and information about the resources held by the user from the register of the current Middleman Infohabitant to the register of the new Middleman Infohabitant (the name tag of which may have been included in the re-register message previously received). Once the relevant information has been copied into the register of the new Middleman Infohabitant, the User Infohabitant - in step 92 - instructs the old Middleman Infohabitant to delete the Name Tag and associated information from its register. Next, in step 94, the User Infohabitant overwrites its Family Tag with the Name Tag of the new Middleman Infohabitant to indicate to the system that it is now associated with the Middleman Infohabitant specified in the aforementioned re-register message. Result Processing

In its simplest form, the result processing code 92 could simply comprise a means for displaying the results of the query on the monitor attached to the workstation of the user represented by the user agent.

Alternatively, the processing of results could be more sophisticated with results from a number of Middlemen Infohabitants being forwarded to the User Infohabitant, and a ranking being applied in accordance with which of the resources found in any given search are deemed to be most relevant.

Ranking of results could be accomplished by a variety of different mechanisms. For example, the User Infohabitants could include code to rank results from Middleman Infohabitants before passing them to their users for review. Alternatively, the users themselves could do the ranking and pass the results of the ranking back to the Middleman Infohabitant who forwarded the results, and the Middleman Infohabitant could use the ranking to determine which of the providing user agents should be rewarded. As a further alternative, the Middleman Infohabitants could rank the results before passing them to the User Infohabitants.

This ranking can be used to modify the magnitude of the award, since it is indicative of the degree of success of the identification of data; this is described in more detail below. Detailed Description of the Middleman Infohabitant

Fig. 9 is a flow diagram illustrating the functionality of an illustrative Middleman Infohabitant. As shown in Fig. 9, the Middleman Infohabitant is normally in a dormant state cycling through the incoming message detection code 96. If an incoming message should be detected, the Middleman then seeks - in step 98 - to determine the message type with code 1 00(i) to (v) that determines whether the message is a registration message from a User, a query message from a User, a query message from a middleman, a query result from a middleman, or a user exchange message from a middleman. If the message does not fall into any of these categories it is assumed that the message has been sent in error and it is ignored, whereupon the Middleman returns to its dormant state. User Registration Message (100(D)

If the incoming message is determined to be a user registration message, the Middleman invokes user registration code 102 and stores the Name Tag of the User Infohabitant in a register along with the information identifying the information resources held by the user. The identifying information can either be copied from the register of another Middleman (if the User Infohabitant is reregistering (see Fig. 8)), or input by the user (see Fig. 6) if the User Infohabitant has only recently been created. In either event, once the User Infohabitant has been registered with the Middleman, the Middleman returns to the dormant state mentioned above.

User Infohabitant Query Message (100(H))

If the incoming message is determined to be a query message from a user Infohabitant, the Middleman invokes code 104 to determine whether or not an answer to the query can be found in the Middleman's register. By this we mean that the Middleman looks to match keywords of the query with keywords stored in its register. For example, if the user query asks for information relating to "Distributed Information Systems", then the Middleman could search for these keywords in the register. The Middleman could be arranged to search for resources with all of these keywords, or resources with only one or more of the keywords.

If the Middleman finds one or more instances of these keywords in its register, it invokes send answer code 106 to forward an answer to the requesting User Infohabitant. The send answer code 106 may do one of a number of different things. For example, it may simply send back a list of potentially relevant information resources indexed with the identity of the User Infohabitants owning those resources, and leave it up to the user associated with the requesting User Infohabitant to make arrangements for delivery of the resources. In this case, delivery could be accomplished by peer-to-peer communications if the resources are held electronically, or alternatively it could take place by traditional communications means such as by mail or by fax.

Alternatively, the Middleman could send a message to the User Infohabitants owning the resources to request them to return the resources to the Middleman for forwarding to the requesting User Infohabitant. it is also conceivable that the Middleman might, when reporting the answers to the query, include an indication of whether or not the User Infohabitants owning the resources of interest are currently connected to the system.

In a further alternative, the Middleman Infohabitant could hold full copies of each of the information resources owned by each of the User Infohabitants registered therewith, and could forward copies of those resources from its own register in answer to User Infohabitant queries. Such a solution could prove problematic, however, as the resources required to implement the system would be greatly increased and it would not be easy to ensure that all of the resources stored by the Middleman are current versions.

In any event, once an answer has been sent to the User Requester, the Middleman reverts to the dormant state mentioned above. If the Middleman cannot find any resources of relevance in its register (for example if the Middleman cannot match any keywords of the query with resources identified or held in the register), it invokes code 108 to forward the User Query to another Middleman, and then reverts back to its dormant state. Typically, the Middleman Infohabitant to whom the query is to be forwarded is selected at random.

Middleman Infohabitant Query Message (100 (Hi))

If the incoming message is determined to be a query message from another Middleman Infohabitant (known as the sender Middleman), the Middleman invokes code 1 10 to determine whether or not an answer to the query forwarded by the sender Middleman can be found in the Middleman's register. The search through the Middleman's register is accomplished in the same way as the search described above (in relation to code 104) and for brevity will not be explained further.

The results of the search undertaken by code 1 10, irrespective of whether or not the search was successful, are returned by code 1 1 2 to the sender Middleman who forwarded the query. In other words, the Middleman sends a report back to the sender Middleman, and that report may refer to one or more information resources if the search was successful or alternatively if the search was unsuccessful it may simply indicate that no relevant resources were found. Once the report has been sent to the sender Middleman, the Middleman reverts to its dormant state.

Middleman Infohabitant Query Result (WO(iv))

If the incoming message is determined to be a query result message that has been received from another Middleman Infohabitant in response to a User Infohabitant query that had been forwarded earlier (see description above relating to code 108), the Middleman invokes code 1 14 to determine whether the query results message identifies any resources of relevance.

If the results message is empty (i.e. if no resources of relevance were found in the register of the Middleman from whom the query result was received), the Middleman invokes middleman selection code 1 16 to determine whether or not the earlier User Infohabitant Query (forwarded by code 108) should now be forwarded to another Middleman to see if the register of that Middleman includes any resources of relevance.

If the Middleman opts to forward the query to another Middleman it invokes code 1 1 8 and forwards the User Infohabitant query to another Middleman that is typically selected at random.

Typically, the selection code 1 16 includes a counter that is incremented by one each time a previously submitted User query is referred to a new Middleman Infohabitant. If the counter should reach a predetermined value, for example five, then the selection code 1 16 may determine that enough Middleman Infohabitants have been consulted, and the results may then be passed back to the User Infohabitant who posted the query (in the manner described below). The counter is reset to zero each time a new User Query is posted and forwarded to another Middleman Infohabitant by code 108. If the Middleman opts not to forward the query to another Middleman it invokes reporting code 120 and sends a report to the User Infohabitant that posted the query advising that no resources were found which met the parameters of the User Infohabitant's query. Optionally, the Middleman Infohabitant may then invoke code 1 22 to penalise the User Infohabitant who posted the unsuccessful User Query (for the extra drain that it placed on system resources) before reverting to the aforementioned dormant state.

Penalisation of the User Infohabitant, in the preferred embodiment, is accomplished by subtracting one Award from the total number of Awards held by the User Infohabitant who posted the unsuccessful query. Penalisation of the User Infohabitant has several benefits: Firstly, by reducing the number of awards held by a given User Infohabitant, that User Infohabitant is more likely to be exchanged with another Middleman (thereby removing a potentially problematic user Infohabitant. Secondly problematic users can be removed from the grouping system: an awards threshold may be employed so that problematic users (i.e. those who continuously post queries that cannot be answered) can automatically be deleted from the system if their number of awards should drop below the threshold .

If the code 1 1 determines that the results message is not empty (i.e. that the message contains an answer to the User Query forwarded by code 108), then the Middleman invokes code 1 24 to forward the results to the User Infohabitant who requested the information (the requesting User Infohabitant) that was found by code 1 04 not to be present in the Middleman's register.

Once the results have been forwarded to the requesting User Infohabitant the Middleman invokes code 1 26 to reward both the requesting User Infohabitant and the User Infohabitant (registered with another Middleman) owning the resources (the providing User Infohabitant) found in answer to the query. Reward of the requesting and providing User Infohabitants can be accomplished by incrementing the total number of Awards held by each Infohabitant by one. Alternatively, the Middleman Infohabitant can assign awards on the basis of the ranking (see section "Result Processing" above) scheme applied to the results, so that the providing User Infohabitants associated with the resources that were ranked the highest are assigned a higher award than those associated with resources that were ranked less highly. The Middleman then invokes code 1 28 to determine whether the total number of awards held by the providing User Infohabitant is greater that the total number of awards held by the requesting User Infohabitant. If the number of providing User Infohabitant awards is greater than the number of requesting User Infohabitant awards, then the Middleman invokes code 1 30 to instruct the requesting User Infohabitant to re-register with the Middleman of the providing User Infohabitant.

If the number of requesting User Infohabitant awards is greater than the number of providing User Infohabitant awards, then the Middleman invokes code 1 32 to instruct the Middleman with whom the providing User Infohabitant is registered to re-register the providing User Infohabitant with the Middleman of the requesting User Infohabitant.

In either event, re-registration of User Infohabitants is accomplished by means of the scheme set out in Fig. 8, and described above. Essentially the award reflects the "popularity" of a User Infohabitant. For example, a User Infohabitant who either asks more "correct" questions in association with existing documents, or provides more documents to others is popular. So this User Infohabitant will have high rewards. It follows that the award assigned to a providing-only User Infohabitant (described above) is increased in the event that such a providing-only User Infohabitant can answer a query. If a providing-only User Infohabitant with award A provides a document to a User Infohabitant with Award B and A < B, then this providing-only User Infohabitant will have to register with the Middleman associated with the User Infohabitant with award B. It is important to note that the Infohabitants who are re-registered or exchanged in the manner described above have demonstrated (by virtue of the fact that the one owns an information resource which answers the query of the other) that they share at least one topic of interest. Therefore, by moving the User Infohabitant with lower awards to the User Infohabitant with higher awards, it is possible to automatically group the User Infohabitants according to their interests, and so that those Infohabitants who have generally been less successful in their quest for information (i.e. the Infohabitants with lower awards) are associated with those who have been more successful in their quest for information (i.e. the Infohabitants with higher awards) . By grouping Infohabitants in this way, a previously unsuccessful Infohabitant will have a greater likelihood of receiving an answer that has been drawn from the register of the Middleman with whom they are registered (i.e. a prompt answer) the next time that they post a query related to the common topic of interest shared by the requesting and providing User Infohabitants. It is apparent therefore, that this exchange scheme enables the system to automatically organise User Infohabitants into groups or communities that have a common shared interest. Such a system will inevitably provide improvements to the speed at which the system can respond to User queries as it will be more likely, based on previous behaviour, for an answer to a given query to be found locally (i.e. in the register of the middleman with whom the requesting User Infohabitant is registered).

User Infohabitant Exchange Message (100(v))

As mentioned above, if the number of requesting User Infohabitant awards is greater than the number of providing User Infohabitant awards, then the

Middleman invokes code 1 32 to instruct the Middleman with whom the providing

User Infohabitant is registered to re-register the providing User Infohabitant with the Middleman of the requesting User Infohabitant.

Accordingly, if the incoming message is determined to be a user exchange message that has been received from another Middleman Infohabitant, the Middleman invokes change middleman code 1 34 which identifies from the message which User Infohabitant is to change Middleman Infohabitants and then instructs the User Infohabitant to re-register with the Middleman Infohabitant from whom the message has been received in accordance with the scheme shown in Fig. 8.

Illustrative Description of System Operation

An illustrative description of the manner in which the system operates will now be provided in conjunction with Figs. 10a, 10b, and 10c.

With reference to Fig. 10a, a user has inputted a query (i.e. a request for information about a particular subject or topic) to the grouping system 50 (for example via the GUI at their terminal), and the User Infohabitant "U.AGENT(x)" representative of this user in the system has forwarded the query (as shown by the arrow) to the Middleman Infohabitant - in this case "M.MAN(iii)" - with whom the User Infohabitant is currently registered (as shown by the mention of the User Infohabitant's name tag 1 36 in the register 1 38 associated with the Middleman Infohabitant).

The Middleman "M.MAN(iii)" on receipt of the query message from the User Infohabitant searches through its register 1 38 to determine whether any of the information resources mentioned in the register (and hence owned by the other User Infohabitants currently registered with M.MAN(iii)) answer the query forwarded by User Infohabitant U .AGENT(x).

In this example, M.MAN(iii) determines that none of the information resources mentioned in the register would provide an answer to the User Infohabitant query, and forwards (as represented by the arrow linking M.MAN(ii) and M.MAN(ii) in Fig. 10b) the query to one of the other two Middleman

Infohabitants - in this example M.MAN(ii).

On receipt of the user query from M.MAN(iii), M.MAN(ii) searches through its register 140 to determine whether any of the information resources mentioned therein would provide an answer to the query. In this instance, M.MAN(ii) finds that one of the information resources owned by one of the User Infohabitants, (U .AGENT(vi)) registered with it does provide an answer to the query and responds to the query by forwarding a results message (represented by the solid arrow) back to M.MAN(iii) - the Middleman Infohabitant from whom the user query originated. M.MAN(iii) receives the results message and passes it back to User Infohabitant U.AGENT(x) from whom the query emanated. Arrangements can then be made for delivery of the resource to User Infohabitant U.AGENT(x).

Once the results message has been sent back to M.MAN(iii), M.MAN(ii) increments the number of awards 142 held by User Infohabitant (x) and User Infohabitant (vi) from 3 and 5 respectively, to 4 and 6 and determines whether the number of awards held by U.AGENT(vi) is greater than the number of awards held by U.AGENT(x).

As the number of awards held by U.AGENT(vi) is greater than the number of awards held by U.AGENT(x), M.MAN(iii) instructs U.AGENT(x) to un-register from M .MAN(iii) and re-register with M.MAN(ii) .

As shown in Fig. 10c, U.AGENT(x) overwrites its Family Tag 1 44 (which is current set to that of M.MAN(iii) with the Name Tag 146 of M.MAN(ii) and registers both its Name Tag 148 and information pertaining to the information resources it owns in the register 140 associated with M.MAN(ii) . Once registered with M .MAN(ii), U .AGENT(x) instructs M.MAN(iii) to delete its Name Tag and resource information from its register 1 38.

MODIFICATIONS TO PREFERRED EMBODIMENT

It will be understood that a preferred embodiment of the invention has been described above by way of example only, and that modifications and alterations may be made to that embodiment without departing from the scope of the invention as set out in the claims.

For example, it will be apparent to persons skilled in the art that the hardware and software infrastructure described herein is not the only means by which the teachings of the invention may be implemented. For this reason it is important to note that the present invention is not limited to the particular infrastructure described, and that other alternative infrastructures may instead be employed if desired, without loss of functionality.

It is also important to note that the DIET platform is not an essential component of the invention, and that other multi-agent software platforms could instead be employed if desired. For example, the system of the invention could be coded in a language other than an object orientated programming language. Accordingly, whilst the descriptions refers to "agents" and other aspects of an object orientated language, it will be understood by those persons skilled in the art that the system described herein may be coded in any other programming language (such as procedural language for example) and thus that the present invention is not limited to the use of agents, or indeed to implementation with an object orientated programming language. It will also be understood that whilst it is preferred that the invention is implemented by software, it could instead be implemented (at least in part) in hardware comprising, for example, one or more application specific integrated circuits.

It will also be appreciated that the means by which User Infohabitants are created, the means by which search results are processed and the naming scheme for Infohabitants (for example) can be varied for any reason - for example to meet the requirements of the particular software architecture employed. In its broadest terms, the present invention relates simply to an information system comprising middle software entities and user software entities, where the middle software entities are operable to group the user software entities in accordance with the results of searches undertaken by those user software entities. Other modifications that could be adopted would be for each user to be associated with a plurality of User Infohabitants, one for each topic or category that the User is interested in. In such a system the user would elect the most suitable agent (in their opinion) for a given search and instigate the search of the system through that agent. Each of the user agents in such a modified system would operate independently of one another.

As a further alternative, where one user agent is used to represent a user with interests in a number of different topics, that user agent could be provided with an Award for each topic that they are interested in - with user agent exchanges only taking place if the Award for a particular topic of an agent is greater than the Award for that topic of another agent.

In another alternative of particular utility in a very distributed system (for example with users based in different countries) the system could be set up so that a User Query seeking information will be passed, at least in the first instance, to User Agents registered with Middle agents in the same country or time zone as the Middle agent with whom the User Agent issuing the query is registered. In other words, the system could include some sort of location topology so that long distance communications are avoided unless strictly necessary.

In another modification, one or more "User" Agents may not be associated with or under the control of a user of the system or but instead comprise autonomous automated search software programs.

In another modification, the Middle Agents can be adapted so that an exchange will only take place if the difference in Awards between User Agents exceeds a predetermined threshold. Such a modification could prove useful to reserve exchanges for circumstances where the interests of a given user are clearly not matched or similar to those of the other users registered with a given middleman. This approach might prove useful when a given user holds documents on a number of different topics.

As another modification, the Middle agents could hold full copies of the resources owned by the users, but such an approach might cause problems if the resources are subject to updating as the resources held by the middle agents would not then match those held by the users. To combat this problem, the information stored by the middle agents could include a version number, and the user agent owning a given resource could be asked to confirm that the version of a resource is current before that resource is supplied to another user. A further aspect of this modification is that the Middle agents may have access to resources - such as dictionaries or encyclopaedias for example - which are not owned by any User Agent in particular.

In another modification, instead of relaying the first set of positive results from a middle agent to a user agent, the middle agents could be adapted to forward a user query to five (or more or less) middle agents simultaneously and then return all the middle agent search results to the user agent. The user agent (or indeed the middle agent with whom the user agent is currently registered) could then rank the results or otherwise process the results (e.g. filter the results), so that the user is presented with the system's view as to which of the resources is most likely to include an answer to the query, and maybe also a list of those likely resources.

A final point to note is that the grouping system 50 herein described is not limited to use with documents. Rather, the grouping system can be used with MP3 files, photographs, or any other sort of resource for which searchable summary information can be entered into the system. EXPERIMENTAL SYSTEM

Some simple document-finding experiments have been conducted to test the principles of the system, and to demonstrate the functionality and efficiency of the grouping system as a whole.

The experiments have involved simulated local groups of users with documents distributed amongst the users of the groups. In the experimental system, the resources owned by the users are all documents and those documents are classified into ten categories according to their context: Business, Education, Entertainment, Health, Law, Literature, Politics, Sci-tech, Sport, and Travel. In the experimental system every user in the groups is interested in a single category of documents and owns one or more documents of this category.

The experimental system includes fifteen middle agents who mediate between, and facilitate the provision of services to, the users. In the experiment, user queries are assumed to be concerned with finding some other document(s) in their category, which they do not have. The Middle agents are then responsible for locating the users that have those documents.

In addition to searching for suitable documents, the middle agents are also responsible for organising users into communities, so that users with an interest in the same category of documents are grouped together. As has been explained above, the formation of communities makes it easier and faster to find documents in those groups. It may also help with other facilities, such as easy communication, recommendation, and cooperation between users. When the experiments start, user agents are randomly registered with one middle agent. For registration information, users provide the category they are interested in and the titles of documents they hold. For simplicity in the experimental system, the protocol used is very simple: queries are only titles of documents, and answers are the name of searched providers if there are any. If there is no suitable answer in its local database, a middle agent can try at most five other middle agents in the system, which are randomly selected.

In the experiments, the users generate queries continuously in a certain period. The query generation period is distributed normally around a mean Q. Each user has an arbitrary interest in one category of documents and owns random documents in this category. The total documents possessed by ail the users in one category are about 95 percent of all the documents of this category. This guarantees a wide distribution of documents between users and sometimes failed queries in the system. The experiments have been executed with varied number of users and for many different time periods. Every experiment conducted has eventually settled to a stable state with users interested in the same category of documents all clustered into the same group, and all queries being answered with correct results. Figure 1 1 illustrates a screen shot of one experimental system of a hundred users. In some experimental trails, one middle agent is responsible for one community of users (i.e. one category of documents). However, in many other cases, some middle agents are energetic enough to take charge of more than one community. For example, in Figure 1 1 , Middleman3 has taken charge of two categories of documents: Business and Sport. Another impressive result found in the experiments is that some middle agents lose all of their users. These agents are eventually sifted out of communities, such as Middleman22, Middleman 1 73, and Middleman187 shown in Figure 1 1 .

This result implies that not only do middle agents select users, but users also select their middle agents. Thus, very "unpopular" middle agents will eventually be isolated from others and lose the competition of users. This result - arising from the interaction between users and middle agents - provides an economic usage of middle agents, since lost or unpopular middle agents can be easily recognised and removed from the system. When users are not organised according to their preferences (for example when the system has only recently been established), it can take a significant amount of time to find answers to queries. This is because middle agents often need to send requests to other middle agents to obtain correct answers to queries and this increases the communication and processing time. When there are large numbers of users and/or queries, the system is heavily worked and unsuccessful search results are more common.

Once user communities have started forming, however, the system exhibits an improved search time and greater efficiency. This is generally because of the fact that as users that have matched queries and results are gradually grouped together, middle agents can more easily find correct answers in their own groups. As a result there is a decrease in communication between middle agents and hence searches are quicker procedures to undertake. In addition, as the searches get faster, so the rate of successful searches also increases. The system has been tested with varied large numbers of users (for example from 1000 to 5000) to examine its scalability. The experimental results have shown that the number of queries that must be dealt with by middle agents before communities of user agents are formed increases approximately linearly with the number of users. Generally speaking, the experiments have demonstrated that as the organisation of users and of users and middle agents is autonomously undertaken by middle agents, rather than handcrafted by a human designer, the system can organise itself. They have also underlined the fact that Middle agents of the system do not need exact information about user preferences or complex similarity calculations in order to group the users. ALTERNATIVE EMBODIMENT

In the embodiment described above, groups are administered by so-called Middlemen agents 52 [or Middlemen Infohabitants), such that each Middleman agent has a store (register 56), identifying means (104, 1 10, 1 1 2), grouping (1 22, 1 26) and assigning (1 28, 130) means configured to perform the functions described in claim 1 . In a second embodiment (not shown), there are no Middlemen Infohabitants, and there is a store, identifying means, grouping and assigning means associated with each User Infohabitant.

Initially, each User Infohabitant is randomly assigned to a group. Each User Infohabitant 54 has a store (register 56), which includes information about all of the User Infohabitants 54 that are in the same group as that User Infohabitant. When a User Infohabitant initiates a request for information, it firstly accesses its store to identify those User Infohabitants that are in the same group, and sends the request to the identified User Infohabitants. If one of the identified User Infohabitants can provide information relating to the request, the values associated with both the providing and initiating User Infohabitants are increased. If none of the identified User Infohabitants can provide information, the originating User Infohabitant sends the request to a specified number of randomly selected User Infohabitants in other groups, and the User Infohabitants in these groups check whether they can provide information relating to the request.

If none of these queried User Infohabitants can provide such information, the value associated with the originating User Infohabitant is reduced; conversely, if one (or more) of these queried User Infohabitants can provide such information, the values associated with both the providing and initiating User Infohabitants are increased.

If the providing and originating User Infohabitants are not in the same group, the User Infohabitant with a lower value modifies its group details (stored in the store) to the group of the User Infohabitant with a higher value. Thus the User Infohabitant with a lower value effectively moves group. Thereafter, the group details of all of the other User Infohabitants of that group are modified to include details of the newly associated User Infohabitant.

APPENDIX A: Details of the DIET platform

The DIET platform can be installed on one or more computers and used in running distributed applications. It provides software agents that can run processes involved in supporting an application, and in which the user can install processes that are the application. The platform also provides support to the software agents in their interactions with the computers on which they are installed, such as using the computer operating system (OS) to access and coordinate processing capacity, for example by thread allocation, and to store or display results. It also provides support to the software agents in their creation, migration and expiry, and inter-agent communications.

In such a platform, many aspects are variable. The DIET software platform is designed to form the base for information management applications. To be useful in practice, the platform needs to support applications that are: adaptive: Information is updated constantly, and new information is generated. Users of the information, and their preferences, as well as system load and infrastructure, can also change. To operate efficiently, information management applications need to be capable of adapting to such changes. scalable: There is a massive amount of information available in the real world, consider for example the World Wide Web. For an information management system to be useful, it needs to be built without any implicit limits on its size. robust: Failures are inevitable in large-scale, dynamic, distributed systems. Therefore, the system needs to be able to cope with them. It needs to handle failing hardware, as well as cope with high system load. Preferably, performance should slowly decline when parts of the system fail rather than immediately deteriorating. decentralised: A lot of information is located in a distributed form, as the World

Wide Web demonstrates. Decentralisation also helps to enhance scalability, by avoiding critical bottlenecks, and robustness, since it reduces the reliance on particular parts of the system. The DIET platform has been designed with these properties in mind, and has been developed initially with comparatively lightweight agents. By keeping individual agents as lightweight as possible, many more agents can be incorporated in the system, and their numbers can be varied much more easily. While the development of lightweight agents precludes the inclusion of some computationally intensive capabilities at the individual agent level, there is potential for the emergence of such properties in the overall system, through interactions between agents. This emphasis on lightweight agents and bottom-up interaction does not however preclude the incorporation of more heavyweight agents where required when extending this platform. More heavyweight agents may, for example, be needed to include sophisticated reasoning or communication capabilities. Nor does it preclude the use of more top-down Artificial Intelligence techniques, which complement and enhance the functionality provided by bottom-up interactions.

The lightweight, bottom-up design contributes to the aim of supporting adaptive responses in the platform. Lightweight agents more easily serve as the subject of population-based adaptive, evolutionary, algorithms. In addition, the diversity of configurations possible in interactions between lightweight agents should assist the search for robust solutions, and allow easy modification if these are not initially found.

The flexibility of the design approach of the DIET software platform means that it is capable of supporting, for example, a variety of different information manipulation applications, based upon a set of information processing operations that will be required by some or all applications. It is also a useful tool for the study of research issues concerning interactions in multi-agent systems. The DIET platform is written in the Java programming language, and Java (as is well known) is an object-oriented programming language. As a consequence of this, all components of the system mentioned here are "objects" in the object-oriented programming sense. Since DIET is Java based, it follows that it will run on any computer that has a suitable Java Virtual Machine installed. Interaction with the system by a user or users will take place (as is usually the case in Java systems) via a graphical user interface (GUI) displayed on the user's computer monitor and via input devices such as a mouse or a keyboard. Further details concerning the

Java programming language may be found at: "www.java.sun.com".

Claims

1 . Grouping apparatus for grouping users together, wherein each user is represented by an entity (54) that is operable to perform certain tasks on behalf of the user, and each entity is associated with one of a plurality of groups; the apparatus comprising a store (56) arranged to store data (57, 59) in respect of a plurality of such entities, the data identifying one or more characteristics of the users represented thereby identifying means (104, 1 10, 1 12) arranged to receive input from such an entity and to identify stored data that matches the received input, the identifying means being operable to identify an entity associated with the identified data assigning means (122, 126) arranged to assign a value to an entity, the value being indicative of the degree of success of said identification of data grouping means (128, 130) arranged to group entities together on the basis of their respective assigned values the apparatus being arranged, in use, such that in response to receipt of input from an originating entity, the identifying means identifies data, from the store, that matches the received input, and in the event that the identifying means successfully identifies such matching data, the assigning means increases both the value associated with the originating entity and the value associated with entity corresponding to the identified data, whereupon the grouping means compares the respective values, and, if there is a difference between the values, groups the entity having the lower value with the group associated with the other entity, thereby grouping users associated with the said entities together.

2. Apparatus according to claim 2, wherein the storage is distributed such that data corresponding to an entity associated with a group is stored in a store associated with the group.

3. Apparatus according to claim 1 or claim 2, wherein the identifying means is distributed such that there is one identifying means associated with each group.

4. Apparatus according to any one of the preceding claims, wherein the identifying means is distributed such that there is one identifying means associated with each user entity.

5. Apparatus according to claim 3 or claim 4, wherein the identifying means associated with the group corresponding to the originating entity is arranged to search its own storage first and then send a request to identifying means associated with another group, the request comprising an instruction to search its associated store in respect of the received input.

6. Apparatus according to claim 5, wherein the search request is sent to a specified number of groups.

7. Apparatus according to any one of claims 4 to 6, wherein the identifying means is arranged to receive a request comprising an instruction to search its associated store in respect of requested data, the requested data corresponding to the received input, and being sent from a identifying means associated with a different group.

8. Apparatus according to any one of the preceding claims, wherein each entity includes registering means (88) arranged to register and un-register the entity with a group.

9. Apparatus according to any one of the preceding claims, wherein the assigning means is distributed such that there is one assigning means associated with each group.

10. Apparatus according to claim 9, wherein each assigning means is arranged to monitor the value associated with an entity, and, in the event that a value falls below a specified threshold, the assigning means is operable to remove the corresponding entity from the group.

1 1 . Apparatus according to claim 9 or claim 10, wherein the assigning means associated with the group corresponding to the originating entity is operable to assign the values to the originating entity and the entity associated with entity corresponding to the identified data.

1 2. Apparatus according to any one of the preceding claims, wherein the grouping means is distributed such that there is one grouping means associated with each group, the grouping means associated with the group corresponding to the originating entity being operable to control the said grouping of entities.

1 3. Apparatus according to any one of the preceding claims, wherein the or each identifying means that identifies matching data is arranged to forward the matching data to the originating entity.

14. Apparatus according to any one of the preceding claims, wherein, in the event that the identifying means fails to identify any such matching data, the assigning means is arranged to reduce the value associated with the originating entity.

1 5. A method of grouping users together, each user being represented by an entity that is operable to perform certain tasks on behalf of the user, wherein each entity is connected with a group and has data identifying one or more respective user characteristics associated therewith, and wherein each entity has a value, which is indicative of the degree of success of the entity either to respond to an input or to receive a response in respect of an input originating therefrom, associated therewith; the method comprising receiving input from an originating entity identifying data that matches the received input, and, if any such matching data is identified, identifying the entity associated with the matching data increasing the values associated with both the value associated with the originating entity and the value associated with entity corresponding to the identified data, and if there is a difference between the values, grouping the entity having the lower value with the group associated with the other entity, thereby grouping users associated with the said entities together.

1 6. A method according to claim 1 5, in which, if no such matching data is identified, the value associated with the originating entity is reduced.

1 7. A method according to claims 1 5 or 1 6, including monitoring the value associated with an entity, and, in the event that a value falls below a specified threshold, removing the corresponding entity from its respective group.

1 8. A method according to any one of claims 15 to 1 7, further including forwarding the identified data to the originating entity.

1 9. A method according to claim 18, including receiving data indicative of the degree to which the forwarded data satisfies the input and modifying the values in accordance with the received data.

20. An information system comprising: means operable to establish a plurality of requesting or providing entities each operable to instigate a search of said information system or provide information to the information system; and means operable to establish a plurality of management entities, each including a register for recording the identity of one or more of said plurality of requesting or providing entities and information pertaining to information resources of said one or more requesting or providing entities, said management entities being operable to process said searches; wherein said management entities are operable to group said requesting or providing entities in communities that are each registered with at least one management entity on the basis of the results of said searches.

21 . Computer program means operable to establish grouping apparatus according to anyone of claims 1 to 14.

22. A computer program, or a suite of computer programs means comprising one or more software portions operable, when executed in an execution environment, to implement one or more of the method steps of any one of claims 1 5 to 19.