[go: up one dir, main page]

WO2003030024A1 - Systemes d'information - Google Patents

Systemes d'information Download PDF

Info

Publication number
WO2003030024A1
WO2003030024A1 PCT/GB2002/004409 GB0204409W WO03030024A1 WO 2003030024 A1 WO2003030024 A1 WO 2003030024A1 GB 0204409 W GB0204409 W GB 0204409W WO 03030024 A1 WO03030024 A1 WO 03030024A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
entity
infohabitant
middleman
data
Prior art date
Application number
PCT/GB2002/004409
Other languages
English (en)
Inventor
Fang Wang
Original Assignee
British Telecommunications Public Limited Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Publication of WO2003030024A1 publication Critical patent/WO2003030024A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9535—Search customisation based on user profiles and personalisation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9538—Presentation of query results

Definitions

  • This invention relates to information systems, and in the preferred embodiment to distributed information systems arranged to manage information on behalf of users.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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;
  • Fig. 1 1 is a screen shot of an experimental system maintained by a network of computing resources.
  • 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.
  • 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
  • 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).
  • 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.
  • 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.
  • the web server 20 comprises a store for the applets and software for retrieving and distributing applets in response to requests from users.
  • the DIET platform architecture has three layers, a core layer 10, an Application Reusable Component (ARC) layer 1 2 and an application layer 14.
  • ARC Application Reusable Component
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • grouping apparatus is generally referred to as a grouping system 50.
  • the groups are administered by so-called Middlemen agents 52 (which are "Middlemen" type Infohabitants).
  • 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 .
  • 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.
  • 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.
  • Middleman User Infohabitants can be un-registered with that middleman and reregistered with another Middleman.
  • all information in the system is owned by the user agents, but as will later be explained this need not be the case.
  • 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 are middle agents in the system and act as intermediaries between users agents.
  • 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.
  • searching for answers to User queries is accomplished via a Search Scheme
  • evaluation of user behaviour is accomplished via an Award Scheme
  • exchange of User Infohabitants is accomplished via an Exchange Scheme.
  • every Middleman Infohabitant has a database which records the information held by the User agents registered with it (other alternatives will later be described).
  • 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.
  • 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.
  • a Middleman Infohabitant 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
  • 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.
  • a Middleman 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.
  • the Mid r dleman determines whether the requester User Infohabitant and the provider User Infohabitant are both in its group or 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.
  • middle agents can provide useful services for users, and also recognise and group users with similar interests.
  • 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.
  • search results i.e. the behaviour exhibited by user agents.
  • 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.
  • 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.
  • 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
  • Fig. 6 illustrates the steps of a User Infohabitant creation process 60.
  • 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.
  • 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.
  • identifying information such as - for documentary resources - titles, authors or the like
  • 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.
  • step 72 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.
  • 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.
  • 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.
  • 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.
  • the User Infohabitant invokes code 86 to determine whether or not the message sent is an instruction to re-register with another middleman.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • the User Infohabitant - in step 92 - instructs the old Middleman Infohabitant to delete the Name Tag and associated information from its register.
  • 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.
  • 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.
  • 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.
  • the User Infohabitants could include code to rank results from Middleman Infohabitants before passing them to their users for review.
  • 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.
  • 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.
  • Fig. 9 is a flow diagram illustrating the functionality of an illustrative Middleman Infohabitant.
  • 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)
  • 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.
  • the Middleman invokes code 104 to determine whether or not an answer to the query can be found in the Middleman's register.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • the Middleman reverts to its dormant state.
  • the Middleman invokes code 1 14 to determine whether the query results message identifies any resources of relevance.
  • 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.
  • 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 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • a query i.e. a request for information about a particular subject or topic
  • the grouping system 50 for example via the GUI at their terminal
  • 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 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).
  • 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
  • M.MAN(iii) 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).
  • M.MAN(iii) 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).
  • M.MAN(iii) instructs U.AGENT(x) to un-register from M .MAN(iii) and re-register with M.MAN(ii) .
  • 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) .
  • U .AGENT(x) instructs M.MAN(iii) to delete its Name Tag and resource information from its register 1 38.
  • the DIET platform is not an essential component of the invention, and that other multi-agent software platforms could instead be employed if desired.
  • 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.
  • the means by which User Infohabitants are created, the means by which search results are processed and the naming scheme for Infohabitants can be varied for any reason - for example to meet the requirements of the particular software architecture employed.
  • 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.
  • 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.
  • 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.
  • the system could include some sort of location topology so that long distance communications are avoided unless strictly necessary.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the experiments have involved simulated local groups of users with documents distributed amongst the users of the groups.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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 .
  • Middlemen agents 52 or Middlemen 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, 130) means configured to perform the functions described in claim 1 .
  • there are no Middlemen Infohabitants there are no Middlemen Infohabitants, and there is a store, identifying means, grouping and assigning means associated with each User Infohabitant.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • OS computer operating system
  • the DIET software platform is designed to form the base for information management applications.
  • 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
  • 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.
  • Java programming language may be found at: "www.java.sun.com”.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Dans un mode de réalisation, la présente invention se rapporte à un système d'information comprenant : des moyens capables d'établir une pluralité d'entités de recherche (54), chacune de ces dernières pouvant amorcer une recherche dans ledit système d'information ; et des moyens capables d'établir une pluralité d'entités de gestion (52), chacune de ces dernières comprenant un registre (56) permettant d'enregistrer l'identité (57) d'une ou plusieurs desdites entités de recherche (56) et des informations (59) relatives aux ressources informationnelles de la ou lesdites entités de recherche (54), lesdites entités de gestion (52) étant capables de traiter lesdites recherches. Lesdites entités de gestion (52) sont capables de regrouper lesdites entités de recherche (54) en communautés d'entités de recherche, dont chacune est enregistrée avec au moins une entité de gestion (52), sur la base des résultats desdites recherches.
PCT/GB2002/004409 2001-09-28 2002-09-27 Systemes d'information WO2003030024A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP01308319 2001-09-28
EP01308319.1 2001-09-28

Publications (1)

Publication Number Publication Date
WO2003030024A1 true WO2003030024A1 (fr) 2003-04-10

Family

ID=8182306

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2002/004409 WO2003030024A1 (fr) 2001-09-28 2002-09-27 Systemes d'information

Country Status (1)

Country Link
WO (1) WO2003030024A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1826943A1 (fr) * 2006-07-31 2007-08-29 Siemens Aktiengesellschaft Procede pour rechercher information dans un réseau

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998033135A1 (fr) * 1997-01-28 1998-07-30 Firefly Network, Inc. Procede et un dispositif ameliores permettant de recommander des articles grace a un systeme automatise de filtrage cooperatif
WO2000077967A2 (fr) * 1999-06-15 2000-12-21 Nextpage, Inc. Serveur web mandataire capable de personnalisation utilisateur pouvant etre augmente de façon intelligente

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998033135A1 (fr) * 1997-01-28 1998-07-30 Firefly Network, Inc. Procede et un dispositif ameliores permettant de recommander des articles grace a un systeme automatise de filtrage cooperatif
WO2000077967A2 (fr) * 1999-06-15 2000-12-21 Nextpage, Inc. Serveur web mandataire capable de personnalisation utilisateur pouvant etre augmente de façon intelligente

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ROCHA L.M.: "Adaptive Webs for Heterarchies with Diverse Communities of Users", WORKSHOP FROM INTELLIGENT NETWORKS TO THE GLOBAL BRAIN: EVOLUTIONARY SOCIAL ORGANIZATION THROUGH KNOWLEDGE TECHNOLOGY, 3 July 2001 (2001-07-03) - 5 July 2001 (2001-07-05), Brussels, pages 1 - 35, XP002209508, Retrieved from the Internet <URL:http://www.c3.lanl.gov/~rocha/GB0/GB0.pdf> [retrieved on 20020808] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1826943A1 (fr) * 2006-07-31 2007-08-29 Siemens Aktiengesellschaft Procede pour rechercher information dans un réseau
WO2008014907A1 (fr) * 2006-07-31 2008-02-07 Nokia Siemens Networks Gmbh & Co. Kg Procédé pour chercher des informations dans un réseau

Similar Documents

Publication Publication Date Title
US11354315B2 (en) Method and apparatus for stress management in a searchable data service
Yao et al. Recommending web services via combining collaborative filtering with content-based features
Rong et al. Personalized web service ranking via user group combining association rule
Birukov et al. Implicit: An agent-based recommendation system for web search
US20040205076A1 (en) System and method to automate the management of hypertext link information in a Web site
Lin Optimal Web site reorganization considering information overload and search depth
Busetta et al. Extending multi-agent cooperation by overhearing
Kubek et al. The WebEngine: a fully integrated, decentralised web search engine
Shakshuki et al. A multi-agent system architecture for information gathering
Marsh et al. The ACORN multi-agent system
Mukhopadhyay et al. Multi‐agent information classification using dynamic acquaintance lists
Velásquez et al. A methodology to find web site keywords
De Vel et al. A collaborative filtering agent system for dynamic virtual communities on the web
WO2003030024A1 (fr) Systemes d&#39;information
Wu et al. 6S: Distributing Crawling and Searching Across Web Peers.
Wang et al. Extensible soft semantic web services agent
Mattox et al. Software agents for data management
Han et al. A memorization learning model for image retrieval
Carter et al. Architectural Components of Information–Sharing Societies
Choi et al. Multi-agent web information retrieval: neural network based approach
Saha CourseCluster: A Distributed Course Registration System for Efficient Student Enrollment
Kovaľ et al. Intelligent support for information retrieval of web documents
Ali Self Ranking and Evaluation Approach for Focused Crawler Based on Multi-Agent System.
Jie et al. A Multi-agent framework for expertise location
Amamiya et al. An Agent-Oriented Personalized Web Searching System

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FR GB GR IE IT LU MC NL PT SE SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase