Agent system and information processing method for same6662207
Abstract
A system smoothly performing information processing is realized by dynamically making a decision, when it becomes necessary for an agent currently located at a platform to make use of another platform, with regard to whether to cause the agent to move to the other platform or cause the agent to cooperate with another agent that exists at the other platform. The dynamic decision is made in response to situations, resulting in enabling the unified utilization of mobile and stationary agents. The decision of using either movement or cooperation is typically made based on platform information and agent information. Even if planning changes the plan of an agent and regardless of what agent is using which platform's resources, it is possible to easily establish whether movement or cooperation is to be used, based on the platform profile and agent attributes. Such a system can perform information processing in response to changing situations.
Claims
What is claimed is:
1. A computer-readable storage medium storing a program for performing information processing by causing an agent to act in a network that has a plurality of platforms, said program comprising:
means for causing a computer to make a decision, when an agent currently located at a platform needs to make use of another platform, whether to cause the agent to move to the other platform or cause the agent to cooperate with another agent that exists at the other platform, based on at least one of a platform profile and an agent profile;
means for causing a computer to cause the agent to move to the other platform when such a decision has been made;
means for causing a computer to cause the agent to cooperate wit the other agent that exists at the other platform when such a decision has been made; and
means for causing a computer to manage at least one of said platform profile which represents information that is used as a basis for a judgment with regard to agent movement for each platform and that includes information with regard to whether each of the platforms can accept a transferred agent and support the operation of the agent and said agent profile which represents information that is used as a basis for a judgment with regard to movement for each agent and that includes information with regard to whether each of the agents has the ability to move between platforms,
wherein said platform profile, for each platform, represents information that includes at least one item selected from a group consisting of:
a) whether a function to cause agent movement exists;
b) whether reliability of a network circuit related to the platform is high or low;
c) whether it is possible to have an agent exist indefinitely;
d) what types of actions are recognized for an agent;
e) what types of programming languages can be executed;
f) whether the platform will mainly manage processing for agent movement;
g) what types and quantities of resources are to be provided;
h) what types of agents exist;
i) what services are to be provided; and,
j) from when until when is action to be done.
2. A computer-readable storage medium storing a program for performing information processing by causing an agent to act in a network that has a plurality of platforms, said program comprising:
means for causing a computer to make a decision, when an agent currently located at a platform needs to make use of another platform, whether to cause the agent to move to the other platform or cause the agent to cooperate with another agent that exists at the other platform, based on at least one of a platform profile and an agent profile;
means for causing a computer to cause the agent to move to the other platform when such a decision has been made;
means for causing a computer to cause the agent to cooperate with the other agent that exists at the other platform when such a decision has been made; and
means for causing a computer to manage at least one of said platform profile which represents information that is used as a basis for a judgment with regard to agent movement for each platform and that includes information with regard to whether each of the platforms can accept a transferred agent and support the operation of the agent and said agent profile which represents information that is used as a basis for a judgment with regard to movement for each agent and that includes information with regard to whether each of the agents has the ability to move between platforms,
wherein said agent profile, for each agent represents information that includes at least one item selected from a group consisting of:
a) whether the agent has the ability to move between platforms;
b) whether processing for agent movement is to be done mainly by the agent;
c) what types and quantities of resources are required by the agent;
d) from when until when is action to be done;
e) in what programming language the agent action is to be described; and
f) what types of services are required by the agent.
3. A computer-readable storage medium storing a program for performing information processing by causing an agent to act in a network that has a plurality of platforms, said program comprising:
means for causing a computer to make a decision, when an agent currently located at a platform needs to make use of another platform, whether to cause the agent to move to the other platform or cause the agent to cooperate with another agent that exists at the other platform, based on at least one of a platform profile and an agent profile;
means for causing a computer to cause the agent to move to the other platform when such a decision has been made;
means for causing a computer to cause the agent to cooperate wit the other agent that exists at the other platform when such a decision has been made;
means for causing a computer to manage at least one of said platform profile which represents information that is used as a basis for a judgment with regard to agent movement for each platform and that includes information with regard to whether each of the platforms can accept a transferred agent and support the operation of the agent, and said agent profile which represents information that is used as a basis for a judgment with regard to movement for each agent and that includes information with regard to whether each of the agents has the ability to move between platforms;
means for causing a computer to generate an agent plan that satisfies a given request;
means for causing a computer to cause an agent to act by causing the agent to execute the generated agent plan;
means for causing a computer to store information required for agent action;
means for causing a computer to cause an agent at a platform either to move to another platform or to cooperate with another agent at another platform;
means for causing a computer to store knowledge requirement for generation of said agent plan, said movement, and said cooperation; and
means for causing a computer to manage said knowledge.
4. A computer-readable storage medium storing a program for performing information processing by causing an agent to act in a network that has a plurality of platforms, said program comprising:
means for causing a computer to make a decision, when an agent currently located at a platform needs to make use of another platform, whether to cause the agent to move to the other platform or cause the agent to cooperate wit another agent that exists at the other platform, based on at least one of a platform profile and an agent profile;
means for causing a computer to cause the agent to move to the other platform when such a decision has been made;
means for causing a computer to cause the agent to cooperate with the other agent that exists at the other platform when such a decision has been made;
means for causing a computer to manage at least one of said platform profile which represents information that is used as a basis for a judgment with regard to agent movement for each platform and that includes information with regard to whether each of the platforms can accept a transferred agent and support the operation of the agent, and said agent profile which represents information that is used as a basis for a judgment with regard to movement for each agent and tat includes information with regard to whether each of the agents has the ability to move between platforms; and
means for causing a computer to handle an exception that occurs when an agent is to be moved between platforms, wherein said means for causing a computer to handle the exception comprises:
means for causing a computer to store exception descriptions representing what type of handling is to be done for what type of exception; and
means for causing a computer to handle an exception, based on one of said exception descriptions.
5. The computer-readable storage medium according to claim 4, wherein said one of said exception descriptions represents what type of handling is to be done for at least one exception selected from a group consisting of:
(1) an exception that an agent cannot be moved occurs because communication with a platform that has been specified as the movement destination has failed;
(2) an exception that an agent cannot be moved because the movement destination specification is invalid;
(3) an exception that an agent cannot be moved because the platform specified as the movement destination does not have a section configured to accept the agent and causing the agent to act; and
(4) an exception that an agent cannot be moved because of insufficient resources at the platform specified as the movement destination.
6. The computer-readable storage medium according to claim 4, wherein said one of said exception descriptions includes:
information with regard to which of a plurality of communication circuits have a low reliability; and
information that represents what type of handling is to be done wit respect to an exception that can occur when an agent is moved between platforms through a low-reliability communication circuit.
7. A computer-readable storage medium storing a program for performing information processing by causing an agent to act in a network that has a plurality of platforms, said program comprising:
means for causing a computer to make a decision, when an agent currently located at a platform needs to make use of another platform, whether to cause the agent to move to the other platform or cause the agent to cooperate with another agent that exists at the other platform, based on at least one of a platform profile and an agent profile;
means for causing a computer to cause the agent to move to the other platform when such a decision has been made;
means for causing a computer to cause the agent to cooperate with the other agent that exists at the other platform when such a decision has been made;
means for causing a computer to manage at least one of said platform profile which represents information that is used as a basis for a judgment wit regard to agent movement for each platform and that includes information wit regard to whether each of the platforms can accept a transferred agent and support the operation of the agent and said agent profile which represents information that is used as a basis for a judgment with regard to movement for each agent and that includes information with regard to whether each of the agents has the ability to move between platforms; and
said means for causing a computer to make the decision further comprising means for causing a computer to make a judgment as to whether to move an agent immediately when the agent is to be moved to another platform.
8. A computer-readable storage medium storing a program for performing information processing by causing an agent to act in a network that has a plurality of platforms, said program comprising:
means for causing a computer to make a decision, when an agent currently located at a platform needs to make use of another platform, whether to cause the agent to move to the other platform or cause the agent to cooperate with another agent that exists at the other platform, based on at least one of a platform profile and an agent profile;
means for causing a computer to cause the agent to move to the other platform when such a decision has been made;
means for causing a computer to cause the agent to cooperate with the other agent that exists at the other platform when such a decision has been made;
means for causing a computer to manage at least one of said platform profile which represents information that is used as a basis for a judgment with regard to agent movement for each platform and that includes information with regard to whether each of the platforms can accept a transferred agent and support the operation of the agent, and said agent profile which represents information that is used as a basis for a judgment with regard to movement for each agent and tat includes information with regard to whether each of the agents has the ability to move between platforms; and
said means for causing a computer to make the decision further comprising means, when there exist a plurality of platform candidates for the movement destination, for causing a computer to select a platform from said plurality of candidates to which the movement is made.
9. A computer-readable storage medium storing a program for performing information processing by causing an agent to act in a network that has a plurality of platforms, said program comprising:
means for causing a computer to make a decision, when an agent currently located at a platform needs to make use of another platform, whether to cause the agent to move to the other platform or cause the agent to cooperate with another agent that exists at the other platform, based on at least one of a platform profile and an agent profile;
means for causing a computer to cause the agent to move to the other platform when such a decision has been made;
means for causing a computer to cause the agent to cooperate with the other agent that exists at the other platform when such a decision has been made;
means for causing a computer to manage at least one of said platform profile which represents information that is used as a basis for a judgment with regard to agent movement for each platform and that includes information wit regard to whether each of the platforms can accept a transferred agent and support the operation of the agent and said agent profile which represents information that is used as a basis for a judgment with regard to movement for each agent and that includes information with regard to whether each of the agents has the ability to move between platforms; and
said means for causing a computer to make the decision further comprising means, when an agent is to be moved to a plurality of platforms in sequence, for causing a computer to determine the sequence of the platforms to which the agent is to be moved.
10. A computer-readable storage medium storing a program for performing information processing by causing an agent to act in a network that has a plurality of platforms, said program comprising:
means for causing a computer to make a decision, when an agent currently located at a platform needs to make use of another platform, whether to cause the agent to move to the other platform or cause the agent to cooperate wit another agent that exists at the other platform, based on at least one of a platform profile and an agent profile;
means for causing a computer to cause the agent to move to the other platform when such a decision has been made;
means for causing a computer to cause the agent to cooperate with the other agent that exists at the other platform when such a decision has been made;
means for causing a computer to manage at least one of said platform profile which represents information that is used as a basis for a judgment with regard to agent movement for each platform and that includes information with regard to whether each of the platforms can accept a transferred agent and support the operation of the agent, and said agent profile which represents information that is used as a basis for a judgment with regard to movement for each agent and that includes information with regard to whether each of the agents has the ability to move between platforms;
means for causing a computer to make a judgment as to whether to cause an agent at the platform to move to another platform or to cause another agent at the other platform to move to the platform; and
means for causing a computer to indicate a result of the judgment to the agent to be moved.
11. A computer program for performing information processing by causing an agent to act in a network that has a plurality of platforms, said program comprising:
means for causing a computer to make a decision, when an agent currently located at a platform needs to make use of another platform, whether to cause the agent to move to the other platform or cause the agent a cooperate wit another agent that exists at the other platform, based on at least one of a platform profile and an agent profile;
means for causing a computer to cause the agent to move to the other platform when such a decision has been made;
means for causing a computer to cause the agent to cooperate with the other agent that exists at the other platform when such a decision has been made;
means for causing a computer to manage at least one of said platform profile which represents information that is used as a basis for a judgment with regard to agent movement for each platform and that includes information with regard to whether each of the platforms can accept a transferred agent d support the operation of the agent, and said agent profile which represents information that is used as a basis for a judgment with regard to movement for each agent and that includes information with regard to whether each of the agents has the ability to move between platforms.
12. The computer program according to claim 11, wherein said platform profile, for each platform, represents information that includes at least one item selected from a group consisting of:
a) whether a function to cause agent movement exists;
b) whether reliability of a network circuit related to the platform is high or low;
c) whether it is possible to have an agent exist indefinitely;
d) what types of actions are recognized for an agent;
e) what types of pro g languages can be executed;
f) whether the platform will mainly manage processing for agent movement;
g) what types and quantities of resources are to be provided;
h) what types of agents exist;
i) what services are to be provided; and,
j) from when until when is action to be done.
13. The computer program according to claim 11, wherein said agent profile, for each agent, represents information that includes at least one item selected from a group consisting of:
a) whether the agent the ability to move between platforms;
b) whether processing for agent movement is to be done mainly by the agent;
c) what types and quantities of resources are required by the agent;
d) from when until when is action to be done;
e) in what programming language the agent action is to be described; and
f) what types of services are required by the agent.
14. The computer program according to claim 11, further comprising:
means for causing a computer to generate an agent plan that satisfies a given request;
means for causing a computer to cause an agent to act by causing the agent to execute the generated agent plain;
means for causing a computer to store information required for agent action;
means for causing a computer to cause an agent at a platform either to move to another platform or to cooperate with another agent at another platform;
means for causing a computer to store knowledge required for generation of said agent plan, said movement, and said cooperation; and
means for causing a computer to manage said knowledge.
15. The computer program according to claim 11, further comprising:
means for causing a computer to handle an exception that occurs when an agent is to be moved between platforms, herein said means for causing a computer to handle the exception comprises:
means for causing a computer to store exception descriptions representing what type of handling is to be done for what type of exception; and
means for causing computer to handle an exception, based on one of said exception descriptions.
16. The computer program according to claim 15, wherein said one of said exception descriptions represents what type of handling is to be done for at least one exception selected from a group consisting of:
(1) an exception that an agent cannot be moved occurs because communication with a platform that has been specified as the movement destination has failed;
(2) an exception that an agent cannot be moved because the movement destination specification is invalid;
(3) an exception that an agent cannot be moved because the platform specified as the movement destination does not have a section configured to accept the agent and causing the agent to act; and
(4) an exception that an agent cannot be moved because of insufficient resources at the platform specified as the movement destination.
17. The computer program according to claim 15, wherein said one of said exception descriptions includes:
information with regard to which of a plurality of communication circuits have a low reliability; and
information tat rep cuts what type of handling is to be done with respect to an exception that can occur w n an agent is moved between platforms through a low-reliability communication circuit.
18. The computer program according to claim 11, said means for causing a computer to make the decision further comprising means for causing a computer to make a judgment as to whether to move an agent immediately when the agent is to be moved to another platform.
19. The computer program according to claim 11, said means for causing a computer to wake the decision farther comprising means, when there exists a plurality of platform candidates for the movement destination, for causing a computer to select a platform from said plurality of candidates to which the movement is made.
20. The computer program according to claim 11, said means for causing a computer to make the decision further comprising means, when an agent is to be moved to a plurality of platforms in sequence, for causing a computer to determine the sequence of the platforms to which the agent is to be moved.
21. The computer program according to claim 11, further comprising:
means for causing a computer to make a judgement as to whether to cause an agent at the platform to move to another platform or to cause another agent at the other platform to move to the platform; and
means for causing a computer to indicate a result of the judgement to the agent to be moved.
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to an improvement in technology for processing information existing in a distributed manner in a network, and more particularly to an improvement in agent-oriented information processing technology that adapts to a change in situations.
2. Description of the Related Art
In recent years, information processing systems such as computers have seen progressive downsizing and advances in the development of network environments, such as the Internet. For this reason, the information processing equipment and methods are largely experiencing a shift to a distributed system in which elements such as data files and function libraries are distributed among nodes in a network. Along with the change, there have been further advancements in providing an open network environment, with local networks of companies and research laboratories, for example, being connected to wide area networks, such networks connected to wide area networks being known as open networks.
In a typical large-scale open network, data files or function libraries that are distributed among a plurality of nodes are often combined to form a single piece of software, this class of software being known as a distributed system. It can be envisioned that such distributed constituent elements can be moved to another node or directory or can be subjected to a change in name or access authority in response to node management or network management situations. In making such changes, however, the following problems arise.
First, when a request is made for software processing, the request is input as a request description such as a message or command. When making this input, specific constituent elements with regard to processing located at a given node are specified. However, when the specified constituent elements are moved to another node, to specify the new destination node, it is necessary to either reenter or correct the input to the software. In particular when part of the software is configured to access a transferred constituent element, the movement of the constituent element changes the configuration of the software itself. In this case, it is necessary to change the accessing software part so as to specify the new destination node.
In the past, because elements such as nodes, functions, and files were named explicitly, when such functions and files were moved, the software or input needed to be changed accordingly. Furthermore, this type of specification needed to be made before the start of processing.
In distributed systems, therefore, in order to configure software to provide flexible response to reliably provide service to users, it is very important to be able to respond flexibly to such changes. In particular in the change of such changes, it is desirable to be able to change a specification even after processing has started and, if at all possible, automatically, without the need for human intervention.
In a network, recent years have seen attention being focused on agent-oriented technologies as a means for implementing such as flexible software architecture. This agent-oriented technology is a software-development technology which aims to make up a piece of software by treating agents as units, an agent being a unit of processing in software, the goal being to achieve autonomous and flexible response to environmental changes. Agents can be classified as mobile agents, which are capable of being moved between nodes that made up a network, and stationary agents, which do not possess such mobility.
An agent system is a system in which an agent performs information processing with the goal of satisfying requests from a user. If a single system uses a plurality of agents, it is possible to perform highly efficient information processing in a distributed system such as a distributed processing network. Such system as to use a plurality of agents is known as a multi-agent system.
The term "node" refers to a logical unit that makes up a network, and if an agent is considered to be a program, a node serves the function of an interpreter or operating system that supports the operation of the agent. This type of node is known as a platform, which can exist as a single computer, and there are cases in which a plurality of nodes exists in one computer.
For example, in the Japanese Unexamined Patent Application publication H7-182174, there is disclosed a method of implementing remote programming. This remote programming is such programming as to transfer an agent from the node at which processing was begun to another node in a distributed system.
(Agent System Example)
Next, an example of an agent system that uses the above-noted agent to implement remote programming will be described. Specifically FIG. 28 is a functional block diagram that shows an example of a mufti-agent system which uses a mobile agent. The agent system that is shown in this drawing has a network 800N that connects a plurality of nodes 800 and, while a large number of nodes 800 can be provided in the system, two representative nodes are shown in FIG. 28. Of the nodes 800, the node that is used by the user in creating an agent will be called the local node (800L) and the node that is the destination for the generated agent will be called the remote node (800R). The local node 800L and the remote node 8008 have mutually similar configurations, and the agents are treated as processes. The term "process" as used herein refers to a unit of processing that is managed by an operating system, and the simultaneous management of a plurality of processes is known as mufti-process management.
In the above-noted mufti-agent system, each node 800 has an input/output means 803 (L, R) for the purpose of the user generating an agent and for receiving the results of information processing that is performed by an agent. An agent management means 804 (L, R) of each node, in addition to being used for generating and deleting an agent, is used to move an agent to another node by transferring information of the agent to the other node, and in the same manner to receive an agent from another node.
If a user wishes to perform some type of information processing using the above-described type of agent system, the user creates an agent at the local node 800L by giving an indication from the input/output means 803L to the agent management means 804L.
Then, in the most basic case, the user issues a script from the input/output means 803L to a generated agent. The script is an action program for an agent, and is described with specific contents that indicate, for example, of which node is to be moved to and what processing is to be performed. As a more specific example of a script, it can be envisioned that movement is to be made to node A, and a copy of file a is to be sent to a user node, after which movement is made to node b, and a copy of file b is sent to a user node. An interpretation/execution means 802 (L, R) that is provided at each node executes such a script so as to apply the agent, thereby achieving the desired object of information processing.
In the above-noted case, an agent information storage means 801 (L, R) at each node stores information required for the agent. In addition to the above-noted script, the information required for the agent includes, for example, the variables necessary for interpretation and execution of the script (these being known as script variables) and, if required, information or files collected by the agent. As instructions described into a script for an agent, in addition to instructions that can be executed at only a single node, there are movement instructions which cause movement of an agent from one node to another. The interpretation/execution means 802L sequentially executes instructions of the script and, if it is necessary to execute a movement instruction, it specifies the destination node and issues a request to the agent management means 804 to move the agent. In this case, the agent management means 804L would perform the following processing to transfer the agent.
Specifically, the agent management means 804L issues a request via the network 800N to the agent management means 8048 at the remote node 8008 to prepare to accept the agent. When this is done, the agent management means 8048 that receives this request performs preparation for accepting the agent, such as assignment of resources and making settings of processes that perform agent management, after which it issues a notification to the agent management means 804L at the local node 800L that these preparations have been completed.
Upon receiving the above-noted notification, the agent management means 804L reads and agent information such as the script and the internal agent status at the time of interpretation and execution of the above-noted movement instructions from the agent information storage means 801L, and transfers this agent information to the remote node 8008. The agent management means 8048 of the remote node 8008 first stores the transferred agent information in the agent information storage means 8018, and then notifies the interpretation/execution means 8028 of having done so, whereupon interpretation and execution begins.
When the agent transfer is successfully completed in the above-noted manner, the agent management means 804L at the local node 800L ends the process, and releases now-unnecessary resources such as memory and CPU time.
At the remote node 8008 to which the agent was transferred, processing proceeds, using the agent information within the agent information storage means 8018. There are cases in which the processing results in completion at the remote node 8008, and cases in which the agent is transferred back to the local node 800L. If the agent is transferred once again in this manner, the script execution will be executed again at the local node 800L. The above-noted remote programming enables flexible processing in a distributed system.
In the above-noted type of remote programming, even if the node configurations differ, if the interpretation/execution means and agent management means and the like are configured to suit the node-specific hardware and operating system while using agent information that is common among the nodes, compatibility can be achieved even among nodes that have different configurations. By adopting this type of configuration, it is possible to transfer and execute scripts to perform the above-noted flexible processing, even among computer systems that have different operating systems and hardware.
For example, in an agent system such as described above, if a user wishes to collect a number of files from the network, an action program (script) to achieve this object can be given to an agent and the agent sent out to the network. The agent that is sent out to the network acts autonomously according to the script that it has been given. For this reason, because there is no need to maintain continuous communications between the user node and the agent, compared with such network functions of the past as ftp and telnet, there is the advantage of immunity to circuit faults.
There is another known prior art for the purpose of performing processing which bridges across a plurality of nodes in a network, this being described in Oren Etzioni and Daniel Weld "A Softbot-Based Interface to the Internet", in Communications of ACM. In this technology such previously available network functions as $p, which is used to perform file transfer, and telnet, which implements a virtual terminal function for the purpose of performing a remote login are used to perform processing that bridges across a plurality of nodes. Software performs trial-and-error use of functions automatically, based on information that is collected during operation, flexible planning being performed in response to situations, so as to select functions in accordance with changes in configuration, such as with regard to files.
For example, if a desired function is transferred to another node, since an attempt to access the function at the node before transfer would fail, planning is performed at the original node, so as to change the access destination to the second candidate for re-access. According to this technology, it is possible to achieve flexible operation in response to status at various points in time. In this technology, the use of functions such as telnet and ftp is done within a range for which compatibility has been ascertained.
When an agent is operating at a particular node, it often must make use of resources such as files and software that are characteristic of other nodes.
In such cases, a stationary agent, which does not have mobility, will cooperate with an agent that exists at another node, making use of contracted network protocols or other procedures. In contrast to this, in the case of a mobile agent, not only will it cooperate, because it can also move to another node to make use of the resources at the other node, it can make use of either cooperation or movement.
If for example, because of the need as noted above to use resources of another node, it is necessary to make use of another node, a mobile agent must be able to either cooperate or move. In the method of the past, in which a script was described beforehand as an action program for a mobile agent, in a case in which either cooperation or movement is required, which is actually performed must be established beforehand as an operational sequence. For this reason, whether cooperation or movement is desirable will differ, depending upon a variety of conditions, such as the reliability and bandwidth of the circuit that connects the nodes, and the node characteristics.
For example, in a case in which an agent will attempt to make use of a resource at another node to which the node where the agent exists is connected by a circuit having low reliability or low bandwidth, movement is more desirable than cooperation. That is, in the case of cooperation, although there is a need to maintain communication between the nodes, over a circuit having poor reliability or low bandwidth, there is a tendency for communications to be broken off, in which case the cooperative processing is interrupted. In contrast to the case of cooperation, if the agent itself moves to the other node, even if the circuit via which the movement was done is broken, there is no problem created at the destination node of the movement, thereby enabling processing to continue. In this case, when the processing is completed, the agent may return to the original node when the circuit status is restored.
Even if an agent at a node is a mobile agent that has a function of mobility, unless another node at which the resource is to be used supports mobile agents, that agent will be forced to cooperate with another agent of the other node. That is, unless the other node has a means for receiving the agent information and causing the agent to act, even if it is possible to transfer the agent to that node, it will not be possible for the mobile agent to continue processing.
Therefore, at the point at which the action program for a mobile agent is described, for each case in which either movement or cooperation is required, it is desirable that various conditions that affect which is desirable be understood and the appropriate selection of movement or cooperation be made. It is difficult, however, to gain a grasp of such various conditions beforehand and, even if it were possible to do understand such various conditions beforehand, there are cases in which a condition changes during the operation of a mobile agent, after the script for the mobile agent is established. For example, as described above, when constituent elements such as distributed files or libraries are to be moved among nodes, the node at which the resource to be used exists itself changes. For this reason, at the point at which the action program for the mobile agent is described, it becomes difficult to establish whether movement or cooperation is the desired choice.
As is clear from the foregoing discussion, in a case in which a mobile agent is required to either move or cooperate, rather than establishing this choice as fixed, it is desirable to be able to establish this dynamically on-the-fly, according to the situations at the required time. However, as described above, in the prior art, in which the action program for a mobile agent was described as a script beforehand, it is necessary to establish beforehand whether movement or cooperation is to be performed, in terms of an operational sequence. In this type of method of the past, therefore, it is clearly difficult to establish whether movement or cooperation is to be done dynamically, in accordance with the situation. In particular, with open-type networks that are of large-scale, because the larger the scale of the network, the more often the software configuration changes, there is a great desire to be able to accommodate this type of change.
When a mobile agent is to be moved to another node, it is not possible for the user of the mobile agent to directly manage the destination node of the movement. For this reason, when some fault occurs at the destination node, it is difficult to take appropriate action with respect to this fault. Additionally, in a case as described above as well, in which communications are cut off because of the low reliability or low bandwidth of the circuit, it is difficult to take appropriate action with respect to such a fault.
That is, in operating a mobile agent, the following two points should be kept in mind. The first point is that it is often the case that one of the major reasons for using a mobile agent is the low reliability or low bandwidth of a communication circuit. For this reason, the major field of application for a mobile agent is that of mobile computing that makes use of a portable terminal. When using such circuits that have low reliability, a large problem is that of what type of action should be taken when exceptions such as errors occur.
The second point is that a mobile agent can be operated on a machine that is out of the management scope of the user. For this reason, when an exception situation occurs in the operation of an agent on such a machine, it is significantly more difficult to take action than it would be in the case if a mobile agent were not being used. In particular when a destination machine that is connected by a communication circuit of low reliability is used, such as noted with regard to point 1, this difficulty becomes prominent.
In addition to the above, in the prior art method of describing the action program for a mobile agent as a script beforehand, because it is necessary to describe all the operational examples of the agent, this operation itself becomes troublesome.
In the method of Etzioni et al, it is necessary to continue mutual access between the local machine and the remote machine and sending and receiving of data. For this reason, there is the problem that if the communication circuit develops a fault during processing that cuts off the access path, it is not possible to continue normal processing. In addition, there, are cases in which it is necessary to make detailed access of information contents at a remote node and to change the type of processing performed, and to perform repeated access of information at a remote node, and cases which demand that processing be performed in real time to some degree, these cases making it more efficient to performing information processing as a process operating on the remote machine.
3. Object of the Invention
Therefore, an object of the present invention is to provide an agent system that, when it is necessary for an agent to perform some task at another node, is capable of dynamically judging at that point, based on the situations at that time, whether to move the agent or have the agent cooperate. Given such an agent system, it is possible to perform highly efficient information processing that is responsive to changes in situation.
SUMMARY OF THE INVENTION
The above-described problems in the prior art are solved by an improvement in agent-oriented technology according to the present invention. In one aspect of the present invention, there is provided an agent system in which processing information is performed by causing an agent to act in a network that has a plurality of platforms. This agent system has a movement means for causing an agent to move between platforms, and a means for causing cooperation to be performed between a plurality of agents. This system further has a decision means for making a decision, when it becomes necessary for an agent currently located at a platform to make use of another platform for the illustrative purpose of utilizing resources of the other platform for the illustrative purpose of utilizing resources of the other node, with regard to whether to cause the agent to move to the other platform or cause the agent to cooperate with another agent that exists at the other platform.
In order to perform the above-noted type of judgment, the above-noted agent system uses some information that serves as a criterion for the judgment. Such information used as, a typical judgment criterion may include information stored in agent profile, such as agent attributes with regard to whether or not the individual agents have the ability to move between platforms. Such information used as the typical judgment criterion also may include information stored in platform profiles, which typically includes information with regard to whether individual platforms are capable of accepting and activating an agent. It is also possible to use information with regard to the reliability of the network circuits that connect the platforms. By storing at least these various types of information as a judgment criterion beforehand, it is easy to make the above noted judgment, based on this judgment criterion. It is also possible to send a test message for either movement or cooperation to the target platform, and then making a judgment based on whether or not a message is returned which satisfies conditions. It is also possible to make the judgment based on whether a file for movement or cooperation having a characteristic file name exists at the target platform.
As a result, even when there is a difference either in the mobility among agents, in the ability to support mobile agents among platforms, it is possible to perform processing with making use of another platform. Similarly, even when there is a difference in the reliability of circuits that connects platforms due to what platforms are combined, it is possible to perform processing with making use of another platform. For example, to move an agent to another platform, it is necessary that both the current platform and the destination platform support the movement and also necessary that the agent itself have mobility. When the reliability of the circuit that connects the platform at which the agent currently exists to another platform is low, since an attempt to perform cooperation could be envisioned as resulting in a possible cutoff of messages midway, movement of the agent would be the appropriate choice.
It is desirable that the above-noted agent system be configured so as to generate and execute an agent plan that satisfies the given requests. In order to create an action plan for an agent that is responsive to the situation and achieve processing with mating use of another node, dynamic selection is made, based on conditions, of whether to cause movement between nodes or to cooperate with another agent. This enables highly efficient information processing that is responsive to changes in the network. Therefore, because it is possible to effectively utilize movement and cooperation of agents by planning in response to network changes, it is possible to perform effective information processing even in an open network.
It is desirable that the above-noted agent system be configured so that it responds to various exceptions when an agent attempts a move between platforms. Examples of exceptions that tend to occur when movement is done include a failed communication with the destination of the move, an invalid specification of the destination, the lack of support of the destination for the mobile agents, and an insufficiency in resources at the destination. The action to be taken in each of these cases is expressed as the exception description. Using this type of exception description, it is possible to effectively handle exceptions when they occur. With regard to a loss of communication because of a low reliability on the communication circuit, it is desirable that information with regard to the reliability of the communication circuit be prepared beforehand at the platform, for example, and to establish beforehand how the loss of communication is to be handled when it occurs on a circuit over which an attempt is made by an agent to move. By doing this, even if the reliability of the communication circuit is low, resulting in a tendency to communication being lost, there is achieved an immunity to impaired operations and failures or the like.
The above-noted agent system can be configured either so that the agent itself manages a procedure for movement to another platform, or so that the platform is the focus of the management. By selecting dynamically whether a series of processing procedures related to the movement is to be performed chiefly by the agent or chiefly by the platform, the degree of freedom with regard to how the agent moves is increased. This enables an improvement in the autonomy of the agent and the overall processing efficiency.
It is also possible for the above-noted agent system to be configured so as to select an appropriate movement tinning, and to select an appropriate destination from a plurality of destination platform candidates. It is also possible when an agent moves sequentially to a plurality of platforms, to establish an optimum sequence of movement, responsive to conditions. These improvements enable an improvement in the system processing efficiency.
It is further possible for the above-noted agent system to be configured so that it issues an indication for movement between platforms in response to the status of each platform. Because it is possible to dynamically assign agents to each of the platforms in response to platform status, it is possible to improve the system processing efficiency.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram that shows an example of an agent system that uses planning.
FIG. 2 is a flowchart that shows the processing procedure in an agent system that uses planning.
FIG. 3 is a conceptual diagram that shows the life cycle of an agent in an agent system that uses planning.
FIG. 4 is a functional block diagram that shows the configuration of the first configuration of the present invention.
FIG. 5 is a conceptual diagram that shows an example of the problem in the first configuration of the present invention.
FIG. 6 is a drawing that shows an example of platform profiles in the first embodiment of the present invention.
FIG. 7 is a drawing that shows an example of agent attributes in the first embodiment of the present invention.
FIG. 8 is a drawing that shows an example of exception description in the first embodiment of the present invention.
FIG. 9 is a drawing that shows an example of information with regard to reliability of communication circuits in the first embodiment of the present invention.
FIG. 10 is a conceptual diagram that shows a field in the first embodiment of the present invention.
FIG. 11 is a conceptual diagram that shows the blackboard part of the first embodiment of the present invention.
FIG. 12 is a flowchart that shows the processing procedure in the first embodiment of the present invention.
FIG. 13 is a conceptual diagram that shows a plan being generated in 5 the first embodiment of the present invention.
FIG. 14 is a conceptual diagram that shows a completed plan in the first embodiment of the present invention.
FIG. 15 is a flowchart that shows a specific procedure of a plan in the first embodiment of the present invention.
FIG. 16 is a flowchart that shows the procedure of a contract net protocol in the first embodiment of the present invention.
FIG. 17 is a flowchart that shows the procedure for movement of an agent between platforms in the first embodiment of the present invention.
FIGS. 18-21 are conceptual diagrams, each of which shows the midway progress to achieving the goal in the example of the problem in the first embodiment of the present invention.
FIG. 22 is a block diagram that shows the overall configuration of the second embodiment of the present invention.
FIG. 23 is a functional block diagram that shows a specific configuration of a platform in the second embodiment of the present invention.
FIG. 24 is a functional block diagram that shows a specific example of the data format in the platform profile in the second embodiment of the present invention.
FIG. 25 is a function block diagram that shows a specific example of the data format in the agent profile in the second embodiment of the present invention.
FIG. 26 is a flowchart that shows the processing procedure in the second embodiment of the present invention.
FIG. 27 is a flowchart that shows the procedure for either processing at another platform by either movement or cooperation in the second embodiment of the present invention.
FIG. 28 is a block diagram that shows an example of an agent system of the past.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
Embodiments of the present invention are described below, with references made to relevant accompanying drawings. The present invention is generally implemented by a computer that has peripheral device and software that controls the computer, in which case the software is a combination of instructions that follow the description of the present invention in this document, parts of the invention that are from the prior art making use of prior art methods that were described in the foregoing section on background art. This software is not limited to program code, and includes data that is prepared for use at the time the program code is executed.
The software implements the effect of the present invention by using physical resources which may include a processing unit such as a CPU, a coprocessor, or a chip set, an input device such as a keyboard or a mouse, a storage device such as a memory or a hard disk drive, and output devices such as a display or a printer.
It should be noted that various configurations of specific software and hardware can be used to implement the present invention. For example, the software can be in various forms, such as a compiler, an interpreter, or an assembler and, it is possible to perform communication with the external by means of a removable storage medium such as a floppy disk, or a network connection unit. A storage medium such as a CD-ROM onto which is stored a program or software for implementing the present invention alone forms one aspect of the present invention. Additionally, part of the functions of the present invention can be implemented in a physical electronic circuit, such as an LSI device.
Because, as described above, there are various methods that can be envisioned for implementing this present invention using a computer, virtual circuit blocks that implement the individual functions of the present invention and the embodiments thereof will be used to describe the present invention and embodiments thereof below.
(Example of a Configuration that Uses Planning)
The inventors have continued research with regard to an agent system that is, in response to changing situations, capable of changing a script that serves as an action program for an agent, in contrast to the agent system of the past as shown in FIG. 28.
Specifically, in recent years, with networks of increased scale and complexity, and particularly with connections being made to open networks such as wide-area networks such as the Internet, changes in constituent elements of the network, such as the location of files, occur frequently. In an agent system such as shown in FIG. 28, however, because a fixed script is given to an agent at the time it is created, it is not possible to change the action of the agent in response to changing situations. Accordingly, the inventors proposed an agent system that has a planning function, as a technique for automatically changing the action of an agent without the need for human intervention, this being disclosed in the Japanese Unexamined Patent Application publication H9 176181.
In the above-noted technology, the agent action program is known as a plan, and the generation of this plan is known as planning. Using this technology, by re-generating a plan in response to a situation, accommodation is achieved with respect to changes in constituent elements of the network. When it is required to accommodate to changes in network configuration and the like, or when a plan execution has failed, the re-generation of a planning executed in the present invention is known as replanning.
FIG. 1 shows the functional block diagram of an example of the configuration of such an agent system. In this technology, the information used in generating a plan are information known as "knowledge" and action definitions. Of these, "knowledge" includes a variety of information that is used in agent operation, and particularly in planning, one example of this being information with regard to constituent elements of the network, such as the node locations of files. For example, in the example shown in FIG. 1, knowledge with regard to this type of network is stored in a local information storage means 1L and, when there is a change in the network configuration, an updating means 2L is caused to reflect this change, by means of automatic detection or manual operations or the like. An action definition as noted above is a constituent part of a plan, and consists of information with regard to what types of instructions (actions) can be used, this being stored in an agent information storage means 3L.
In an agent system as noted above, a user which issues instructions to create an agent issues a goal to be achieved to a node, instead of issuing a script. This goal is a status that is to be achieved as the object of information processing, described in a pre-established grammar. A plan generating means 5L combines various actions included in the action definitions while referencing the given knowledge, thereby generating a plan for the purpose of achieving the goal. In such an agent system, because a change in the network configuration is reflected in an agent plan via knowledge at the time of planning or replanning, it is possible for an agent to flexibly accommodate itself to a change in situation, without human intervention.
Furthermore, a means for generating a plan such as this is called a "planner", and this is actually implemented as a type of program that represents the planning procedure. The broad concept of calving the agent action program and each of the parts thereof is the script, and the term "plan" is used to refer to the overall script that is generated by an agent that performs planning as shown in FIG. 1.
(Example of an Action Using a Plan)
Next, a specific, operating procedure for an agent system that uses planning such as described above will be described, using the example shown in FIG. 2. In this procedure, a user inputs the description (request description) for a request to the agent as an information processing goal (step 201), whereupon the required initialization is performed (step 202), after which a plan is generated (step 203). This processing is ended based on the results of a judge as to the ending conditions such as whether the goal has been achieved (steps 204 and 205).
Specifically, until these ending conditions are satisfied (step 204), the plan required to be executed to achieve the goal is executed. In the execution of the plan, instructions included in the plan are sequentially executed (steps 206 and 208) and, if a instruction to be executed is a movement instruction (step 207), processing to move an agent between nodes (referred to as a "go" action) is executed (step 209). If the execution of an instruction or a go action has failed, a new plan is generated, if necessary (step 203).
(Agent Life Cycle)
Next, the life cycle of an agent which performs the above-noted planning will be described, with reference being made to FIG. 3. Specifically, with the entry of the goal, an agent goes into action, this starting at the planning phase P According to the generated plan, the agent transfers from the planning phase P either to the execution phase E, in which the plan is executed, or to the movement phase M, in which movement between nodes is done. According to the generated plan, the agent acts while transferring among the phases in response to failure of execution or movement if it occurs. Once the initially given goal is achieved, normal termination is made. However, if the goal has not been achieved and the planning itself has failed, the termination is made as an overall failure.
1. First Embodiment
(1. Configuration)
(1-1. Overall Platform Configuration)
This embodiment is an information processing apparatus in which an agent on a network formed by a plurality of mutually connected nodes performs processing of information. FIG. 4 is a block diagram that shows the configuration of one platform that makes up this embodiment.
In FIG. 4, the reference numeral 1 denotes an agent management section, which manages an agent. This agent management section 1 has a configuration (to be described later) that is required to implement planning, movement of an agent on network N, and cooperation between agents. The reference numeral 2 denotes a planning section, which generates a plan, this plan being the procedure that is to be executed by an agent for the purpose of satisfying a given request. The reference numeral 3 denotes an execution section that causes an agent to act by executing a plan that is generated in this manner. The reference numeral 4 denotes an agent information storage section, which stores information required for the agent to operate, this being, for example, the above-noted plan and variables that represent the internal status of the agent.
The reference numeral 5 denotes a knowledge storage section, which stores a variety of information (to be described later), such as knowledge required for planning and knowledge with regard to computers connected by a communication circuit having low reliability. The reference numeral 6 denotes a knowledge management section, which manages the knowledge storage section 5, this knowledge management section 6 performing processing for writing, reading, and correction of various knowledge that is stored in the knowledge storage section 5.
In the above-noted embodiment, each platform has a plurality of fields, these corresponding to different purposes. These fields indicate the scope of knowledge and agent operation. The reference numeral 7 denotes a field management section, which manages resources of the platform by allocating the resources to every field.
The reference numeral 8 denotes a blackboard section, which stores information that is used in controlling cooperation between agents and operation of an agent. The reference numeral 9 denotes a hierarchical blackboard management section, which manages a blackboard hierarchical architecture that represents the control level of the agent action in the blackboard section 8. The reference numeral -10 denotes a platform, which manages the various above-noted sections and which also manages communication on the network, and 20 is an input/output section which outputs information from various other sections, inputs information thereto, and which 5 can input information that controls the status of each section.
(1-2. Specific Problem Example)
Next, FIG. 5 is a conceptual diagram that shows a specific example of an application of the above-noted embodiment to an actual problem. In this example, the problem is that travel ticket reservations are made at platforms 101 through 106, which are connected by the communication circuits C 1 through C5. Specifically, in the example shown in FIG. 5, the reference numeral 101 denotes a portable computer that a user can carry around, this computer being capable of entering a network N in this embodiment by means of a cellular telephone or PHS telephone radio circuit, this circuit allowing connection and disconnection at any time. FIG. 4 shows an example of a platform that can be joined to the network.
By mating use of the network via the above-noted portable computer 101, a user makes ticket reservations for modes of travel and a travel plan from Tokyo to a given university in a given region (which shall be called a "regional university").
In FIG. 5, the reference numeral 102 denotes a computer at a travel agent, this computer storing a variety of information with regard to computers that can be used for travel plan and travel ticket reservations on the network. The reference numerals 103 and 104 denote the computers of airline companies AL1 and AL2, respectively, 105 is a computer of a tourist bureau that covers the area in which the regional university is located, and 106 is a computer of the destination regional university.
Each of the computers 101 through 106 has stored in it information required for the travel plan and ticket reservations, to be described later. These computers 101 through 106 will hereinafter simply be referred to as the "travel agent", the "regional university", and the "tourist bureau`.
(1-3. Contents of the Knowledge Storage Section)
Next, just what type of information is included in the knowledge storage section 5 of the platform 10 shown in FIG. 4 will be described. This knowledge storage section 5 is the section that, stores knowledge required for plan generation, for movement of an agent between platforms, and for cooperation of agents, more specifically this knowledge storage section 5 stores planning knowledge 51, a platform profile 52, agent attributes 53, and exception description 54.
(1-3-1. Knowledge for Planning)
Of the above knowledge, the planning knowledge 51 is used in generating an agent plan, and this can include network configuration knowledge with regard to which files reside at which platforms, knowledge with regard to what type of planning is to be done in what cases, and various types of knowledge in accordance with the object of using the information processing system and the agent.
(1-3-2. Platform Profile)
The platform profile 52 is information with regard to whether each of the platforms can accept a transferred agent and support the operation of the agent, that is, information with regard to whether the platform supports mobile agents. An example of a platform profile 52 is shown in FIG. 6. This example corresponds to the various platforms that are shown in FIG. 5, and stores information with regard to whether or not each of the platforms, such as the portable computer (101 in FIG. 5) or the travel agent (102 in FIG. 5) can support a mobile agent.
(1-3-3. Agent Attributes)
The agent attributes 53 are information with regard to whether or not each of the agents has mobility, that is, the ability to move between platforms, FIG. 7 showing an example of agent attributes 53. This example corresponds to the example that is shown in FIG. 5, information being stored with regard to each of the agent names, concerning the platform to which that agent belongs and whether or not that agent is mobile, this being represented by the attribute "mobility`.
The value of the mobility attribute is set at "mobile" if the agent is a mobile agent and at "stationary` if the agent is a stationary agent, this enabling the distinguishing of the existence or non-existence of mobility in each of the agents. These attribute values can be distinguished by a flag that is included in the agent information, and that indicates whether or not the agent has mobility, and by whether or not there is information with regard to movement between platforms.
The agent management section 1 can then judge and hold the agent attributes from the above-described information when an agent is newly created or when a moved agent is accepted.
The membership information represents the platform to which a stationary member belongs, or the platform at which a mobile agent is generated.
(1-3-4. Exception Description)
The exception description 54 is the expression of what type of handling is to be done of various types of exceptions that could occur when an attempt to made by an agent to move between platforms, an example of such exception description being shown in FIG. 8. In this example, the details of the handling of the following types of exceptions arc set forth.
(1) The exception that an agent cannot be moved occurs because communication with a platform that has been specified as the movement destination has failed (communication time-out).
This is the case in which a notification is made to the destination platform that there is a desire to move an agent, but no response is received from that platform within a given period of time.
(2) The exception that an agent cannot be moved because the movement destination specification is invalid (move destination specification error).
This is the case in which an error is made in specifying the destination 30 of a move. For example, it can be envisioned that this type of exception would occur when an invalid platform or domain II) is specified at the destination of a move. This type of exception can occur, for example, when an attempt is made to move an agent from the platform at which it was generated to another platform.
(3) The exception that an agent cannot be moved because the platform 5 specified as the movement destination does not have a means for accepting the agent and causing it to act (no mobile support).
This is the case in which the platform specified as the destination of a move does not have a function that enables support of a mobile agent. This type of exception can occur, for example, when an attempt is made to move an agent from the platform at which it was generated to another platform.
(4) The exception that an agent cannot be moved because of *insufficient resources at the platform specified as the movement destination (insufficient destination resources).
This is the case in which the platform specified as the destination of a move normally has the ability to accept and support operation of an agent, but happens at the time to not have sufficient resources such as memory to enable acceptance of the agent. This type of exception can occur, for example, when an attempt is made to made to move an agent from the platform at which it was generated to another platform and, after the transfer of agent data for the purpose of the move, the transferred agent restarts to operate at the destination platform.
In the case of the communication time-out exception noted in (1), the handling of the exception will differ between the case of the exception occurring on a communication circuit of high reliability and the case of the exception occurring on a low-reliability communication circuit. For this reason, the exception description for this exception includes information with regard to the low-reliability communication circuit.
(1-3-5. Information with Regard to Low-Reliability Communication Circuits)
This "low-reliability communication circuit information" is information with regard to which circuits of the communication circuits C1 through C5 that are shown in FIG. 5 have low reliability, an example of such information being shown in FIG. 9. In this example, the information stored is that, for each of the communication circuits C1 through C5, the information with regard to which platform (connection destination 1) is connected to which platform (connection destination 2) through the computer circuit and with regard to whether the communication circuit has high or low reliability. In FIG. 5, communication circuits with high reliability are indicated by bold solid lines, and communication circuits with low reliability are indicated by thin broken lines.
To simplify the description that follows, the reliability of the communication circuits between nodes are noted as single communication circuits. In reality, however, in a network such as the Internet, which has no hub, the reliability of a communication circuit between one platform and another platform is established by the reliabilities of a plurality of communication circuits. In such cases, it is possible to store the reliability of a communication circuit in terms of the reliability for each of a combination of communication circuits, or to calculate the reliability of a given path from the reliabilities of a plurality of communication circuits that make up that path.
While low-reliability communication circuit information will be described later, when a communication time-out occurs when communication occurs in an attempt to move an agent between platforms, this information can be used to check whether the currently used communication circuit has a high or a low reliability, and the "communication time-out (low-reliability communication circuit)" shown in FIG. 8 is the expression of what kind of accommodation is to be made when a communication time-out occurs when movement of an agent is attempted over a communication circuit that has low reliability.
(1-4. Configuration of the Agent Management Section)
The agent management section 1, in addition to performing management of an agent at a platform, is also the section that, by making requests to agents for agents to move to another platform or by making requests to an agent at another platform to perform processing, uses resources at another platform. In addition to having a configuration (not shown in the drawing) for generating an agent, registering an agent, and deleting an agent, this agent management section 1 has a cooperation section 11, a movement section 12, a decision section 13, an exception handling section 14, and a time-out detection section 15.
Of the above sections, when an agent uses a resource of another platform, the cooperation section 11 issues a request from that agent for processing to an agent of the other platform, this being specifically made up of a task announcement, bidding deadline, and an awarding of the task for the purpose of executing a contract network protocol. When an agent uses a resource of another platform, the movement section 12 serves to move the agent to the other platform. More specifically, the movement section 12 is configured so as to perform such processing as an overture of an agent movement to a platform specified as a destination in, for example, a plan, and to transfer information that is stored in the agent information storage section 4.
When an agent uses a resource of another platform, the decision section 13, based on the platform profile 52 and the agent attributes 53, makes a decision of either to move the agent to the other platform, or to issue a request from that agent to an agent at another platform to perform processing.
The exception handling section 14 is the section that performs action in response to exceptions, based on the exception description 54, the exception handling section 14 and exception description 54 forming an exception accommodating means for the purpose of handling exceptions that occur when an attempt is made by an agent to move between platforms. The time-out detection section 15 is the section that detects that there has been no response on a communication circuit for a given period of time, this being used in combination with the exception description for the case of a communication time-out on a communication circuit that has a low reliability.
The above elements, when communication is performed for the purpose of moving an agent using a communication circuit having low reliability, in the case in which the time-out detection section 15 detects a loss of communication, the exception handling section 14 acts so as to repeat the communication after the lapse of a pre-established amount of time, thereby effectively handling the exception.
(1-5. Field)
As noted above with regard to the field management section 7, each platform has a plurality of fields, which correspond to different purposes. These fields are regions of operation of an agent specified for each purpose and field of information processing, these being known as fields. A plurality of such fields can exist in a single platform, and the field management section 7 performs management, by each field, of resources such as memory and information used in the generation and execution of plans.
Turning to FIG. 10, we see a conceptual diagram that shows an example in which a plurality of hosts (machines) H are connected with a network N, one platform, this being a node X, existing at each of the hosts H, and a plurality of fields FL existing at a node X. In an agent system such as this, the knowledge used to generate a plan is divided between the fields FL, so that when an agent is retrieving information that is necessary for planning, it is not necessary to access excessive information, thereby improving the efficiency of information processing. Knowledge that is used in planning can be classified into platform knowledge that the platform has and agent knowledge that the agent has.
(1-6. Blackboard)
The blackboard management section 9 is configured so as to make a hierarchical division of the blackboard 8 into a plurality of hierarchical levels, based on the priority of the information, thereby controlling each of the agents, including the cooperative operation thereof. That is, as shown in FIG. 11, the blackboard 8 has an upper hierarchical level and a lower hierarchical level, and in the case of an unpredicted network change, for example information that needs to be quickly transferred between agents, this information would be written into the upper hierarchy of the blackboard. With respect to this, the blackboard management section 9 is configured so as to cause processing of this type of information to interrupt the normal operation of the agent. By doing this, it is possible to control the operation of an agent in response to unpredicted changes in the situations of the network. (1-7. Other Aspects of Platform Configuration)
While FIG. 4 shows the example of the configuration of a single node, that is, the configuration of a single platform, this is merely one example of many platforms that are included in the above-noted embodiment of an information processing apparatus, and it can be envisioned that there are other platforms having a configuration that is partially different from that shown. For example, in a platform that does not support a mobile agent, there is no need for the movement section 12 or the time-out detection section 15. Additionally, when performing exchange of information between agents, when using a blackboard 8 and a blackboard management section 9 of one specific platform, there is no need for other platforms to have a blackboard 8 or blackboard management section 9.
As an additional example, it is possible to have a platform that does not have a planning function, and such a platform does not need to have the planning knowledge 51 and the planning section 2. In a platform that does not have a plurality of fields, the field management section 7 would be unnecessary.
(2. Action)
An embodiment of the present invention configured as described above operates in the following manner.
FIG. 12 is a flowchart that shows the processing procedure of this embodiment.
(2-1. Input of Request)
First, a user inputs a request to the system via the input/output section 20 of a portable computer (step 301). The status to be achieved as a result of information processing is expressed by describing in a pre-established format. For example, the user inputs a request with regard to a travel itinerary and ticket reservation as noted below.
Departure location: Tokyo
Departure time: November 3
Arrival location: Regional university
Arrival time: By noon, November 3
Transportation means used: Air
(2-2. Conversion to a Goal)
A request that is entered as indicated above is then converted to a goal (step 302). This goal is expressed as the status to be achieved by information processing by the agent, in a format that can be processed by the agent and the planning section 2. For example, the above-noted request with regard to a travel itinerary and ticket reservation is converted to the following goal.
plan_and_reserve_tickets([
departure_place(tokyo),
departure_date(11,3),
arrival_place(a_university),
arrival_date(11,3),
arrival_time(by,12,0),
transport(air)])
(2-3. Agent Initialization)
When the request is converted to a goal as noted above, the platform agent management section 1 creates an agent to be used in the achievement of the goal, and executes a procedure for initialization (step 303). For example, if an agent is created with the name "user," the initialization procedure would perform such processing as registering the name "user` in a list for the purpose of agent management, setting the prescribed initial values of internal variables of the agent user, and allotting a time slice (CPU time) of the time-sharing system to the agent user.
In a platform in which there are a plurality of fields (FIG. 10), each agent is generated within a specific field, under management of the agent management section 1. Then, in subsequent planning performed by the planning section 2, the knowledge management section 6 reads out and provides knowledge with respect to that field.
(2-4. Planning)
Next, the planning section 2 generates a plan by planning for the purpose of achieving the goal to which conversion had been done (step 304). In this process, the planning knowledge 51 includes information as to what type of operations the agent can execute, this being a part of the plan. This type of operational unit is known as an action, and pre-conditions and post-conditions are established beforehand for each such action.
A pre-condition is a condition that is required before execution of an action, and a post-condition is a condition that is created by the execution of the action. For this reason, if a post-condition that is a given action is achieved, an action that has that post-condition as a pre-condition can be executed. For example, to perform the operation of "copy a file," a necessary pre-condition is "file exists at the current platform," and the post-condition "copy of file exists" is a result of performing the action of copying. Specifically, the process of generating a plan is one of discovering an action that creates the ultimate goal as a post-condition, then discovering another action that creates the pre-condition of the above-noted action as its post-condition, this processing being continued until the status (current status) before execution of the plan is joined to the ultimate goal status by a series of actions. FIG. 13 shows an example of a plan midway in the generation process, in which example the actions which have as post-conditions C5, which is one of the pre-conditions of the action P2, and C7, which is the pre-condition of the action P3, have not yet been found. In this case, a pre-condition that is created as a post-condition by another yet-to-be-found action is known as an unachieved goal.
In the above-noted processing to generate a plan, the causal factor are back-tracked from the goal side, the plan generation process being completed when the status (current status) existing at the start of the execution of the plan is reached. FIG. 14 is a drawing that shows an example of a plan completed by this back-tracking process.
Next, FIG. 15 shows a specific procedure for plan generation. In the procedure shown, part of a goal list into which goals are stored is taken as an unachieved goal list for storage of yet-unachieved goals, such as shown in FIG. 13, with the following processing being performed. First, one unachieved goal at a time is selected (step 402) from the unachieved goal list, until there are no longer any unachieved goals in the goal list (step 401), the following operations being performed, except in the case in which the goal is satisfied (step 403). Specifically, if there is an action that can achieve a pre-condition, which is a goal, by virtue of a post-condition step 404), this action is selected (step 405), the action selected in this manner (selected action) being added to the series of actions (plan tree) such as shown in FIG. 13 (step 405).
In the case in which there is no action that achieves the goal, a judgment is made as to whether or not the goal can be achieved by uncertain knowledge. The term "uncertain knowledge" is used here to refer to the part of knowledge with regard to the network configuration, the specific value of which, such as the truth of which, is unknown unless some processing is done at another platform. In the case in which a goal can be achieved with uncertain knowledge, the action of selecting this uncertain knowledge is added to the action tree (step 405), but if achievement of the goal is impossible even using uncertain knowledge, processing is back-tracked (step 408), so that the action that achieves the current unachieved goal is replaced by another action, and processing is performed again.
For example, with the platform knowledge used by the user, consider the case in which "file a exists at platform A." In this case, if the user gives the goal of obtaining file a, the knowledge that the file exists at platform A will be accessed, so that the plan of the agent that was created will be "move to platform A and send a copy of file a to the platform of the user."
However, if at the point at which the agent moves to platform A file a had been moved to platform B, because file a will not be found, the plan execution will fail, this resulting in replanning at platform A. When this occurs, the platform B knowledge is updated with the movement of the file and, if the change is made to "file a exists at platform B," the contents of the new plan will be changed to "move to platform B and send a copy of file a to the platform of the user." As a result, the agent can autonomously move to platform B, successfully find file a, and send it to the user's platform.
(2-5. Judgment as to Whether Uncertain Knowledge has Been Used)
When a planning procedure such as described above is completed (step 304 in FIG. 12), the decision section 13 makes a decision as to whether or not uncertain knowledge had been used in the planning (step 305). Whether or not uncertain knowledge had been used can be judged based on a recording whenever uncertain knowledge is used in planning, or the judgment can be made by performing a retrieval of the plan that was generated itself, see whether it includes uncertain knowledge.
(2-6. Classification of Uncertain Knowledge)
Because uncertain knowledge is that knowledge which is verified by processing at another platform (which shall be called the target platform), if a plan makes use of uncertain knowledge, in order to achieve the purpose of the plan, it is necessary to verify this uncertain knowledge, the processing for verification of the uncertain knowledge being performed before the execution of the plan.
The decision section 13 makes a decision, for each uncertain knowledge, as to whether verification of the uncertain knowledge is to be performed by moving an agent or by agent cooperation, making, for example, the two classifications of "movement" and "classification` (step 306). By this classification, if the following three conditions (1) through (3) are simultaneously satisfied, the decision section 13 decides to verify the uncertain knowledge by movement. If even one of the conditions is not satisfied, the decision section decides to verify the uncertain knowledge by cooperation.
(1) The reliability of the communication circuit that connects the platform at which the agent resides to the target platform is low.
This is because if * the communication circuit, reliability is high, it is possible to continue communication with the target platform. It is possible to ascertain this type of communication circuit reliability from information with regard to communication circuit reliability (FIG. 9), as follows. For example, the information shown in FIG. 9 include information as to what platforms are connected to what other platforms by each of the communication circuits. For this reason, a search is made for a communication circuit connecting two platforms that coincide with the current platform and the target platform, and the corresponding communication circuit reliability is simply read out.
(2) The target platform supports a mobile agent.
(3) The agent is a mobile agent.
This is because unless the target platform and the agent both support mobility, it is not possible to move the agent or to allow it to operate at the destination platform. With regard to the above two conditions, whether or not the target platform supports a mobile agent can be judged by accessing the platform profile 52 that is shown by example in FIG. 6, and whether or not the agent has mobility can be judged by accessing the agent attributes 53 that are shown by example in FIG. 7.
It should be noted that it is not absolutely necessary to make a decision based on* all three conditions. For example, if it is known beforehand that all of the platforms in a network support mobile agents, it is possible to make a decision based on one or two conditions. If a platform that can verify uncertain knowledge or an agent at that platform is not a mobile agent, it is possible to add to the judgment items whether or not cooperation is supported.
Next, verification of uncertain knowledge is performed, following the above-noted classification. That is, with regard to uncertain knowledge for which a decision has been made that cooperation will be used for verification, the cooperation section 11 performs verification (step 307), based on a contract network protocol, and with regard to uncertain knowledge for which a decision has been made that verification will be done by movement, the movement section 12 performs the verification by moving the agent (step 308).
Because the decision as to whether verification of uncertain, knowledge is to be done by movement or by cooperation is made by the decision section 13 after planning, it is not necessary to specify in the plan whether uncertain knowledge verification is to be done by movement or by cooperation, thereby simplifying the planning procedure and improving the efficiency of processing.
(2-7. Contract Net Protocol Procedure)
Next, the details of a contract net protocol procedure are shown in FIG. 16 (refer to Smith, R. G., "The Contract Net Protocol: High-level Communication and Control in a Distributed Problem Solver", IEEE Trans. Computers, Vol. 29, pp. 1104-1113 (1980)). In the contract net protocol, work that is to be requested by one agent of another agent is known as a task, and the network protocol of making task requests between agents is actually carried out between the cooperation sections 11 of the platforms at which the agents exist.
(2-7-1. Task Announcement)
In the contract net protocol, when a task execution is to be requested, the agent that has the task (hereinafter referred to as the task manager) first, at step 601, broadcasts information (hereinafter referred to as task information) to the group of platforms to which the task request is to be made. The term broadcast refers to the uniform sending of information to a given range of locations, and the sending of task information is known as task announcement. The task information that is broadcast includes such information as a task ID, details of the task, the task manager ID, the plan evaluation criteria, and the bidding deadline.
(2-7-2. Bidding)
A platform that receives task information as described above generates an agent in each field and transfers this task information (step 602). Each agent that receives the task information makes a judgment as to whether or not execution is possible in the field to which it belongs (step 603) and an agent that can execute the contents of the task sends information indicating a desire to bid (known hereinafter as bidding information or a bidding message) to the task manager, that is, the agent makes a bid (step 604). An agent that has sent bidding information is known as a bidding agent.
Bidding information includes, for example, the task ID, the agent ID, and such information as the task execution plan evaluation value, of which the task execution plan evaluation value is the evaluation made by the bidding agent itself as to its execution of the task, based on the plan evaluation criteria indicated by the task announcement.
(2-7-3. Bidding Deadline and Awarding)
The task manager receives bidding information while comparing the current time with the bidding deadline and, when the bidding deadline is reached at step 605, at the next step, 606, a message is sent that indicates the closing of bidding. This bidding closing message is broadcast to all the platforms that were the subject of the request made by means of the task information. At step 609, the task manager decides on the agent to be awarded the task. This decision is made by comparing the bidding information of each of the agents, based on a comparison of the task execution plan evaluation in the bidding information from each of the agents that was received before the bidding deadline with a pre-established decision criterion.
The decision with regard to the agent to be awarded the task (the awarded agent) is the decision of the agent to be specified as the actual destination of the task request. The actual timing of the task request, however, can differ depending upon the type of processing, there being cases in which the request is made immediately after completion of the contract net protocol and cases in which the request is made after waiting a prescribed amount of time.
When the agent to be awarded the task is decided upon, the task manager, at step 610, sends a multicast of awarding information that expresses the details of the award to each of the bidding agents. Upon receipt of this awarding information, the awarded agent goes into the status in which it waits for an execution request to actually execute the task. The task manager subsequently makes a request of the awarded agent to execute the task, resulting in the actual execution of the contents of the task by the awarded agent.
As described above, in this embodiment of the present invention a net contract protocol is used to implement cooperation between agents. When the net contract protocol is used to request processing from another platform, a bidding system is used to achieve harmony between the conditions of the requesting platform and the capacity of the request-receiving platform. By doing this, it is possible to achieve superior overall system processing efficiency.
(2-8. Details of Agent Movement)
The procedure for the case in which an agent is moved between platforms is shown in FIG. 17. In this example, the original platform before the movement of the agent is called the local node, and the destination platform is called the remote node. In this case, the remote node that receives (step 502) the request,(step 501) for movement to the remote node from the local node sets the process for the agent (step 503).
Then, the local node that receives (step 505) a notification sent from the remote node that the setting of the process has been completed (step 504) sends agent information such as the agent plan and variable ranges to the remote node (step 506). Upon receiving this agent information (step 507), the remote node stores the agent information (step 508), sends notification that the movement of the agent has succeeded (step 509), and starts the interpretation and execution of the plan (step 510). Upon receiving the notification of success (step 511), the local node deletes agent processes that are no longer required (step 512).
(2-9. Plan Execution)
At the judgment made at step 305 in FIG. 12, if it is judged that uncertain knowledge is not used in the plan, execution section 3 immediately executes the plan (step 309) and, when the execution succeeds the procedure ends. If the execution fails, however, replanning is performed. In the case in which the plan uses uncertain knowledge, as described above, the contract net protocol (step 307 in FIG. 12) or agent movement is used to verify the uncertain knowledge, at which point, since the plan is substantially completed, the execution section 3 executes the plan (step 309).
While it can be envisioned that there will be variations in the specific configuration and information processing, such as with regard to just what point the above-noted contract net protocol or agent movement is performed, how the results thereof are to be used, and just how replanning is to be done in various situations, one example that can be envisioned is as follows.
In this example, movement is not done uniformly even if the movement conditions have been satisfied, plans for both movement and cooperation being generated and compared, and the most advantageous of the two being executed. In this case, the contract net protocol procedure of step 307 is first used to generate a trial plan to achieve the goal, followed by generation of a plan for movement to a platform which can verify uncertain knowledge, using the agent movement procedure of step 308. Then, these two plans are evaluated in terms of the cost of the amount of data and communication required, the plan being most advantageous in terms of low cost being selected and executed. If the execution fails, the above-noted planning procedure is repeated as replanning.
(2-10. Handling Exceptions at the Time of Movement)
In this embodiment of the present invention, when an attempt is made to move an agent between platforms, even in an exception such as an error occurs, the exception is handled by the exception handling means 14, based on the exception description 54. For example, a case can be envisioned in which, with respect to a plan to move from a local node platform to a remote node platform, during the sending of the execution notification for the movement procedure the response from the destination is cut off, so that time-out occurs.
Specifically, in a case in which a low-reliability communication circuit is used to make a movement, the time-out detection section 15 detects the time-out and notifies the exception handling section 14 thereof this exception handling section 14 performing the following exception handling actions, in accordance with exception description such as shown in FIG. 8.
More specifically, the exception handling section 14 first places the movement section 12 of the destination platform into the waiting status, and retries communication with the destination each time a pre-established amount of time has elapsed. If in this retry process a response is indeed received by the computer at the destination, the movement section 12 continues the normal movement procedure. Subsequently if a break in communication occurs again, the wait status will be enabled once again and, as described above, the retry will be repeated after the waiting time.
(2-11. Information Exchange Between Agents)
When cooperation is performed between agents in response, for example, to a task request as part of the contract net protocol, it is desirable that one agent control the behavior of another agent, so as to be able to flexibly accommodate an unexpected change in situation. In this embodiment of the present invention, the hierarchical blackboard section 8 and blackboard management section 9 that are shown in FIG. 11 are used in the following manner to achieve this flexible accommodation. Specifically, each agent is caused to correspond to one hierarchical level of the blackboard 8, depending upon its priority. In the example that is shown in FIG. 11, the agents 702 and 703 are both placed on a lower hierarchical level of the blackboard 8. The normal information that is sent to other agents is entered on the level having the same priority as the sending agent, the receiving agent accessing the lower level of the blackboard 8 when it has a break in its processing, thereby enabling it to find messages addressed to it.
If an agent enters data into an upper hierarchical level that has a higher priority than its normal priority is set to, this type of entry is detected by the blackboard management section 9, notification of the information being made to the addressee agent of the information by means of, for example, a hardware interrupt. In this manner, this embodiment uses a hierarchically configured blackboard 8, so that information that is entered with a high priority is processed with a higher priority than information with a lower priority.
For this reason, by entering information to be exchanged between agents into a hierarchical level in accordance with its priority, because it is possible to flexibly control the cooperative relationship between agents, the flexible accommodation of unpredicted changes in situation is facilitated. By setting the priority by individual agents, using a higher hierarchical level the higher is the priority of the agent that is exchanging information, and also 30 performing processing of input and output of information with respect to the blackboard 8 with a higher priority, it is possible to perform even further detailed control.
(3. Information Processing Example)
Next, an example of how the above-described operation of this embodiment of the present invention can be used to process the example 5 problem shown in FIG. 5 will be described.
(3-1. Request Input and Initial Planning)
At stage of the initial planning based on the above-noted goal of plan_and_reserve_tickets ( . . . ), because the goal is not yet satisfied, the planning section 2 asks the knowledge management section 6 for an action that satisfies the goal. However, while the portable computer 101 is configured to be able to accept a request, we will assume that it does not have a reservation procedure for the ticket required to achieve the goal.
In the above-noted case, the knowledge management section 6 retrieves planning knowledge from within the knowledge storage section 5, the result being that a judgment is made that there is insufficient action to satisfy the goal. Given this situation, the knowledge management section 6 notifies the planning section 2 that it might be possible to satisfy the goal by using the uncertain knowledge
maybe(plan_and_reserve_tickets(Requirements),ta)
This uncertain knowledge is the knowledge that the ticket reservation procedure might be at the travel agent 102, this being node ta, and the planning section 2 uses this uncertain knowledge to generate a plan. At this point, the relationship between the goal and the uncertain knowledge is as shown in the conceptual diagram presented as FIG. 18. In FIG. 18, established knowledge such as K1 through K5 are represented by solid lines, while uncertain knowledge such as M1 is indicated by-broken lines.
(3-2. Movement to the Travel Agent)
The agent management section 1 asks the knowledge management section 6 what kind of communication circuit makes the connection to node ta, which is the platform which can be used to verify the uncertain knowledge, and whether the agent user and the node to support mobility.
In this case, the knowledge management section 6 accesses information with regard to the reliability of the communication circuits described into the knowledge storage section 5 and, because it discerns that the portable computer 101 is connected to the node to by the communication circuit C1, which has low reliability (refer to FIG. 9), information to that effect in the format of mobile_communication(ta) is returned to the agent management section 1.
In the same manner, the agent management section 1, based on the platform profile 52 and the agent attributes 53 that are stored in the knowledge storage section 5, verifies that both the agent user and the node to support mobility.
In this case, the agent management section 1 verifies the following conditions for the purpose of moving the agent.
(1) The reliability of the communication circuit that connects the platform at which the agent resides to the target platform is low.
(2) The target platform supports a mobile agent.
(3) The agent is a mobile agent.
As a result of checking that the above conditions are satisfied, the planning section 2 generates a plan for movement to the node ta, and the movement section 12. according to this plan, moves the agent user to the node ta.
(3-3. Planning Based on the Reservation Procedure)
At node ta, a reservation procedure that specified uncertain knowledge is found, the uncertain knowledge M1, as shown in FIG. 19, becoming the established knowledge K6. For this reason, the agent performs replanning so as to achieve the goal of resolve_goal(plan_and_reserve_tickets( . . . ) by using the reservation procedure that is indicated by this knowledge K6. As a result, the following plan is generated.
retrieve_route(
departure_place(tokyo),
arrival_place(auniversity));
retrieve_tt;
reserve_tickets;
This plan, as shown in FIG. 19, is a plan to achieve the goal of completion of the reservation by performing processing P1, by which the route is decided, and processing P21, by which the transportation reservations are made. Next, the execution section 3 starts execution of this plan.
(3-4. Retrieving the Route by Movement)
In this execution, first the procedure
retrieve_route(
departure_place(tokyo),
arrival_place(a_university))
is executed. This operation is shown as processing P1 in FIG. 19, and is the operation of retrieving a travel route having its starting point in Tokyo and its arrival point at the regional university. However, because there is no database at the node to with, regard to routes to the regional university, the plan is judged to fail.
This being the situation, the replanning is performed, with the goal being the pre-condition
exists(routeDB(tokyo,a_university))
of the processing
retrieve_route(
departure_place(tokyo),
arrival_place(a_university))
which was the cause of the failed plan execution. This pre-condition means that there exists a route database (DB). As a result of this replanning, the fact that this pre-condition can be satisfied by the uncertain knowledge
maybe(exists(
routeDB(tokyo,a_university),
a_tourist_bureau_site))
is learned from a notification from the knowledge management section 6 (FIG. 19).
The contents of the uncertain knowledge M2 are that a route database might exist at the tourist bureau 105. When the agent management section 1 performs classification with regard to this uncertain knowledge, as seen from the current node to of the agent, the target platform
a_tourist_bureau_site,
which is the tourist bureau 105 is, as expected, learned to be connected by a circuit having a low reliability. As already noted, the agent user supports mobility, as does the tourist bureau target platform 105 (FIG. 6).
For this reason, this uncertain knowledge is also judged to be verifiable by means of movement, the planning section 2 performing planning and execution of a plan for performing retrieval after the movement of the agent to the tourist bureau 105, followed by return to the travel agent 102 once again. This time the processing P1 for retrieving the following information from the database at the tourist bureau 105 succeeds so that, as shown in FIG. 20, the uncertain knowledge M2 becomes the established knowledge K7.
route([tokyo,city1],[city1,a_university])
route([tokyo,city2],[city2,a_university])
The above-noted information signify the existence of a route going from Tokyo to the regional university via city1, and a route going from Tokyo to the regional university via city2. These cities will be treated as City 1 and City 2 hereinafter.
In an example such as this one, by retrieving a route by specifying a method of transportation, the route that is retrieved includes the method of transportation, which in this case is air. In this case, the assumption is made that the portion from Tokyo to City 1 is traveled by air, with the remainder of the trip being made by bus. To simplify the description, the route via City 2 will be omitted, as will illustration of the processing, to be described next, with regard to the time table database.
(3-5. Obtaining the Time Table)
When the retrieval of the route succeeds as described above, the agent user returns to the node ta, which is the travel agent 102, after which the action retrieve_tt (not shown in the drawing), which obtains the time table that corresponds to the retrieved route is executed. When this is done, this action also fails, because there is no time table database for means of transportation from City 1 to the regional university at the node ta, so that replanning is performed. As a result, uncertain knowledge is again obtained, this time to the effect that this database might exist at the tourist bureau 105, whereupon the movement and replanning such as described above are performed.
This time, however, let us assume that the database does not exist at the destination, the tourist bureau 105. In this case, replanning is performed at the tourist bureau, this time resulting in the generation of a plan that uses the uncertain knowledge that the database exists at the regional university 106. Because the regional university 106 does not support mobility (FIG. 6), the decision is made that the verification of this uncertain knowledge should be made by cooperation. As a result, the agent user cooperates with an agent at the regional university, thereby retrieving the time table of a means of transportation (bus) from City 1 to the regional university.
(3-6. Air Reservation by Cooperation)
Next, the agent user attempts to execute the action reserve tickets. In this case, as a result of the processing up until this point, as shown in FIG. 20, reservation processing for both the airplane (P2) and the bus (P3) will be performed. Of these, because the required reservation acceptance database (ticket database) for the plane does not exist at the node ta, replanning is performed, the result being that the uncertain knowledge M4, to the effect that this exists at the two airlines airline 1 and airline2 (these being hereinafter referred to as Airline 1 and Airline 2.
Because it is possible to obtain the knowledge that the computers of the two airline companies are connected by means of communication circuit having high reliability, rather then move the agent, this time the contract net protocol procedure is executed. Using this contract net protocol, the agent user sends the following task announcement message to the agents on the computers of the two airlines 1 and 2 (103 and 104).
task_announce(
plan(ticket_reserved(tokyo,city1)),
cost(price))
This task announcement message means that bids are being entertained for ticket reservations from Tokyo to City 1, based on the evaluation criterion of price.
Upon receiving the above-noted task announcement message, the agents of the airlines perform planning with regard to the goal of
ticket_reserved(tokyo,city1),
the result being that the plan
reserve_ticket(tokyo,city1)
is generated by both agents. Next, the agents of Airline 1 and Airline 2 perform a cost calculation with regard to the generated plans. The cost that is calculated is the price, this being the ticket price, that is included in the task announcement message. As a result of this calculation, let us assume that the ticket prices of the two airlines were 20,000 Yen and 23,000 Yen, respectively.
In this case, the agents of Airline 1 and Airline 2 return the above-noted calculation results to the agent currently operating at the travel agent 102, in the form of a bidding message such as shown below
bid(bidder(airline1_ag1),
reserve_ticket(tokyo,city1),
cost(20000))
bid(bidder(airline2_ag1),
reserve_ticket(tokyo,city1),
cost(23000))
The agent user, upon receiving the above-noted bidding messages, compares the bidded costs, and selects the lower cost. That is, the agent airline1_ag1), of Airline 1 is awarded the task. Then the agent user sends a knockdown message, which represents the awarding of the task, to the selected agent airline1_ag1), of Airline 1, and sends a no-knockdown message, which represents non-awarding of the task, to the agent airline2.agl of Airline 2, which was not selected in the bidding.
(3-7. Bus Reservation)
In this manner, when the processing P2 for the air reservation is completed, the agent user performs one more processing, this being required for the goal of
resolve_goal(plan_and_reserve_tickets( . . . ))
and representing the bus reservation processing P3.
The bus reservation processing P3 requires the existence of a bus reservation acceptance database (DB) as a pre-condition. Because this reservation acceptance database does not exist at the node ta, at which the agent user currently is located, after a failed execution, replanning will be performed, the result of which is the obtaining of a plan that uses the uncertain knowledge that the bus reservation acceptance database might exist at the tourist bureau 105.
Because, as noted above, the tourist bureau 105 satisfies the condition for movement, the agent user is moved to the tourist bureau 105 and searches for the bus reservation acceptance database but cannot find it. Next, a plan is obtained that uses the uncertain knowledge that the bus reservation acceptance database might exist at the regional university 106.
At this point, because the regional university 106 does not support mobility, the contract net protocol is used to perform the processing P3 for making the bus reservation, thereby achieving the ultimate goal of completing the reservations. The overall flow from the original uncertain knowledge to the point at which the final goal is reached is shown in FIG. 20.
(4. Effect)
As described above, in this embodiment information with regard to whether each of the platforms supports mobile agents is prepared in the form of the platform profile 52. Then, when an agent is to use a resource at a different platform, a decision as to whether the agent is to be moved to the other platform or is to request processing (cooperation) with respect to an agent at the other platform is easily made, based on this platform profile 52.
For example, when an agent is to use a resource of another platform, if the circuit connecting to that platform has a low reliability, it is desirable that the agent be moved to that platform. If that platform does not support a mobile agent, however, as can be ascertained from the platform profile 52, there is no need to attempt to move the agent. Instead, the judgment can be made that cooperation should be done with an agent at the other platform. To perform cooperation between a plurality of agents, a known technology for inter-agent cooperation, for example a contract net protocol or blackboard function is used.
In this embodiment, for each agent information with regard to whether the agent is a mobile agent that has the ability to move between platforms or is a stationary agent without the ability to move is prepared in the form of the agent attributes 53. By doing this, when an agent is to use a resource at another platform, the decision of whether to move the agent to the other platform or make a request for processing (cooperation) with respect to an agent at the other platform can be easily made, based on the agent attributes.
In this embodiment, in particular when an agent is to use a resource of another platform, the decision is made based on both the above platform profile 52 and agent attributes 53. For example, if both the agent and the platform support movement, the agent is moved. However, if either one does not support movement, cooperation is done. By doing this, it is easy to make integrated use of mobile agents having the ability to move and stationary agents.
Furthermore, in this embodiment it is possible by planning to flexibly accommodate unexpected changes in the network. Even if planning causes an agent plan to change, regardless of which agent is using the resources of which platform, it is possible to decide, based on the platform profile 52 and agent attributes 53, whether to perform movement or cooperation. In this manner, by making selective use of movement and cooperation, the efficiency of using agents in performing information processing in a distributed network environment is improved. Because planning can be used to accommodate changes in the network as agent movement and cooperation are effectively linked together, it is possible to perform effective information processing in an open-type network.
In this embodiment, even if an exception occurs, such as when movement of an agent between platforms fails, by appropriately handling such exceptions, the smooth processing of information is achieved. In this embodiment in particular, the type of handling to be done in the case of various types of exceptions is expressed in the exception description 54, so that by rewriting this exception description it is possible to easily change the method of exception handling.
Additionally in this embodiment, with regard to exceptions which often occur at the time of movement, these being such situations as failure of communication with the movement destination, invalid specification of the movement destination, lack of support of the destination for mobile agents, and insufficient resources at the destination, by expressing the handling to be done for at least one of these situations in the exception description 54, it is possible to achieve effective handling of exceptions.
In particular in this embodiment, information with regard to which communication circuits have low reliability is prepared as part of the platform profile, for example, beforehand, this being used to decide on handling to be done in the case in which communication is cut off when an attempt is made to move an agent via such a communication circuit. By doing this, it is possible to lessen the chance of faulty operation and failures even in the case of a low-reliability communication circuit which experiences a break in communication.
Specifically, in this embodiment when there is a break in communication for the purpose of moving an agent, communication is retried after waiting some time. For this reason, even if the reliability of a communication circuit is low, the chance of it being possible to move agent information during a period in which the line status is good is increased.
Additionally, in this embodiment the resources of a platform, such as knowledge that is used in planning, are divided and managed by an individual field, based on the purpose of the information processing and application field of the knowledge. For this reason, an agent in a given field need not access knowledge that is not related to its own purpose, thereby enabling efficient planning.
Additionally, in this embodiment urgent information, such as unpredicted changes in the network is, for example, written into a higher hierarchical layer of a blackboard, so that it can interrupt the normal operation of an agent, thereby enabling control of the agent operation to accommodate 5 such changes.
(5. Variations)
Variations of the above-noted embodiment include other examples shown below.
First, the present invention can, of course, be applied to problems other than the ticket reservation problem.
The platform profile 52 (FIG. 6), the agent attributes 53 (FIG. 7), and the exception description 54 (FIG. 8 and FIG. 9) that were shown are merely examples of format and contents. It is, of course, possible to use other formats, and to freely change the items to be included in this information. Also, it is possible for example to store the exception description together with the agent attributes or to store the exception description with correspondence established to such information. In the same manner, it is also possible to make information with regard to the communication circuit reliability not be part of the exception description, but rather store this information as independent information, or to store it as part of the platform profile.
In the above-described embodiment, the platform profile, agent attributes, and exception description and the like are stored in the knowledge storage section of each platform. This is merely an example representing how such type of information is managed. Such type of information can also be implemented as information held by the agent, so that when an agent is transferred to another platform in order to move it to another platform, this information can be transferred together with the agent.
The configuration for handling exceptions, including the exception handling section and exception description and the time-out detection section need not be provided. It is possible that the contents of the exception description are freely established, without regard to the example shown for the above-described embodiment.
Similarly, it is not need to provide a plurality of fields in each platform, and the blackboard section and the blackboard management section need not be provided.
5 2. Second Embodiment
(1. Configuration)
(1.2 Overall Configuration)
First, FIG. 22 is a block diagram that shows the overall configuration of an agent system according to the second embodiment of the present invention. Specifically, this embodiment of agent system, as shown in this drawing, is a computer network in which a plurality of computers (which will be simply called machines) 1100, 1110, 1120, 1130, and 1140 are connected by a network N. An example of a typical machine is the machine 1100, the hardware configuration of which is shown in the FIG. 22.
More specifically, the machine 1100 hardware is formed by a CPU 1101, a main memory 1102, such as a RAM, a hard disk drive 1103 that serves as auxiliary memory, an output device 1104 such as a CRT display or a printer, an input device 1105 such as a keyboard or mouse, a network connection device 1106, and a bus that makes connection between the above-noted hardware elements, the machine 1100 being connected to the network N via this network connection device 1106. The machines 1110 through 1140 have the same type of hardware configuration as the machine 1100.
On a single physical machine, it is possible to have a plurality of nodes, which are the logical units for network management. In this example, however, both nodes and machines will be referred to as machines. At least one platform 1107 is set at each machine 1100, this platform 1107 being the location for action of an agent 1108, and providing the computer resources and services required for agent operation.
A platform 1107 as noted above exists as data on the hard disk drive 1103 before activating and, when activated is loaded into the main memory 1102. The operation of a platform 1107 that has been launched and loaded into the main memory 1102 is implemented by the execution of program code, which is description of platform operation, by the CPU 1101. At the other machines 1110, 1120, 1130, and 1140 as well, in the same manner are set the platforms 1117, 1127, 1137, and 1147, respectively, the description to follow taking the platform 1107 as being representative of the platforms 1107, 1127, 1137, and 1147.
Each of the platforms 1107, as will be described later, has a platform profile that expresses various attributes of the platform as information. This information is held on the hard disk drive 1103 that the platform 1107 uses, and has a structure that will be described later. The configuration, described below, for the purpose of achieving operation of the platform is provided within the platform.
(1-2. Specific Platform Configuration)
FIG. 23 is a functional block diagram that shows the configuration of the platform, as represented by platform 1107, and an agent that operates thereon. In this drawing, the agent is represented by the symbol A. The platform, as shown in FIG. 23, has an agent management section 1001, agent information 1002, a plan execution section 1003, a planning section 1004, and a planning knowledge 1005, which serves as means for operation of the agent on the platform.
Of the above-noted elements, the agent management section 1001 is the section that performs such management functions as creating a new agent, |
