JP2000066895A - Device and method for processing information and recording medium recording software for information processing - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prevent the harmful action of applying overload from an agent to a host. SOLUTION: A third storage part 8 stores information expressing the limit to be satisfied by a plan for the maintenance of a node. While or after the plan is generated, a discrimination part 9 discriminates whether the plan satisfies the limit or not. Concerning the plan discriminated to satisfy the limit, a plan executing part 6 executes the plan while including the movement of the agent between nodes. A fourth storage part 10 stores information (called limit satisfaction metha-knowledge) expressing how to generate the plan satisfying the limit. When it is discriminated the plan does not satisfy the limit, a correction part 11 corrects the plan based on the limit satisfaction metha-knowledge stored in the fourth storage part 10 or acquires information showing the plan satisfying the limit does not exist.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an information processing apparatus and an information processing method for processing information distributed on a network.

[0002]

2. Description of the Related Art In recent years, in information processing system technology centered on computers, downsizing has progressed and network environments such as the Internet have been improved. For this reason, the mainstream of information processing apparatuses and methods is shifting to a distributed system in which components such as data files and function libraries are distributed to each machine on a network. Along with this, even in local networks such as companies and research laboratories, the openness of the environment has been further advanced by connecting to a wide area network. Such a network connected to the wide area network is called an open network.

[0003] In a large-scale network represented by an open network, one piece of software is often configured by combining components such as several data files and function libraries distributed on a plurality of machines. Software configured in this manner is called a distributed system. Distributed components may be moved to another machine or directory, or their attributes, such as names or access rights, may be changed, depending on the management situation of the machine, that is, the node, or the management situation of the network. Conceivable. Such a change causes the following problems.

First, when processing is requested from software, a request description such as a message or a command is input, and at the time of inputting, a specific component related to the processing arranged on a certain machine is designated. . However, when the specified component is moved to another machine, the software must be re-entered or modified to specify the new machine to move to. In particular, when a part of the software is configured to access the moved component, the movement of the component means a change in the configuration of the software itself. In this case, the part of the accessing software must be changed to specify the new machine to move to.

[0005] Conventionally, machines, functions, files, and the like are specifically named, so that when functions or files are moved, software and inputs must be changed in accordance with the changes. In addition, such designation has to be performed before the processing is started.

In a distributed system, in order to reliably provide services to users, it is important to construct flexible software that can adapt to such changes. In particular, in response to such a change, it is desirable that the designation is changed even after the processing is started, and that this change is made automatically without human intervention as much as possible.

In a network, techniques for realizing such a flexible software architecture include:
In recent years, agent-oriented technology has attracted attention and many attempts have been made. The agent-oriented technology is a software development technology for configuring software in units of agents, and the agent here is a unit of processing on software and autonomously and flexibly responds to environmental changes.

For example, Japanese Patent Laid-Open Publication No. Hei 7-182174 discloses a method of performing remote programming. Remote programming is programming in a distributed system in which an agent is transferred from a node where processing is started (called a local machine) to another node (called a remote machine).

For an agent having such a mobile function to be active, instructions and internal information are required. The instruction describes the operation (behavior) of the agent, and the internal information is information operated by the operation of the agent. More specifically, internal information includes variables, arrays, stacks, buffers,
Contains any information related to the operation of the agent, such as queues and flags. The instruction and the internal information are collectively called agent information.

The instruction is described for each unit of various operations such as opening and closing a file. In remote programming, the go operation is used as a special instruction. The go operation allows the agent to be transferred to a remote machine. For example, during a certain process,
If an instruction for a file on another machine is included, a go operation needs to be written and executed prior to the instruction.

FIG. 25 is a functional block diagram showing the configuration of an example of an apparatus for performing remote programming using such an agent. In this device, a local machine L and a remote machine R connected to a network N have the same configuration, and handle an agent as a process. The process referred to here is
It is a unit of processing that is managed by the operating system, and managing a plurality of processes simultaneously is called multi-process.

The agent management means 51L, 51R
For such an agent, it manages processing for the agent itself, such as resource management, setting, termination, scheduling, and transfer. To start processing by the agent, first, the agent information is stored in the agent information storage unit 31L on the local machine L.
To store the agent information in the agent information storage unit 31L, the agent information may be input from the input / output unit 41L or loaded from an external storage device (not shown).

When the start of processing by the agent is instructed from the input / output means 41L, the interpretation executing means 61L
Advances the processing by sequentially interpreting and executing the instructions in the agent information storage unit 31L, and operates the internal information in the agent information storage unit 31L. When the go operation in the instruction is interpreted and executed, the interpretation executing means 61L notifies the agent management means 51L of the interpretation and the agent operation means 51L.
L performs the following process of transferring the agent.

First, the agent management means 51L requests the agent management means 51R on the remote machine R via the network N to prepare for accepting an agent. Upon receiving the request, the agent management unit 51R makes preparations for accepting the agent, such as allocating resources and setting a process to be managed as an agent, and then notifies the agent management unit 51L on the local machine L of the completion of preparation.

Agent management means 5 receiving this notification
1L reads the instructions in the agent information storage means 31L and the internal state of the agent at the time of executing the interpretation of the go operation, and transfers both to the remote machine R. The agent management unit 51R on the remote machine R stores the transferred instruction and internal state in the agent information storage unit 31R, notifies the interpretation executing unit 61R of the fact, and starts the interpretation execution.

When the transfer of the agent is completed successfully,
The agent management unit 51L on the local machine L ends the process and releases resources such as unnecessary memory and CPU time.

In the remote machine R on the transfer side, the processing is continued by using the instructions and the internal state in the agent information storage means 31R. The continued processing may end on the remote machine R, or the agent may be transferred to the local machine L again. When the agent is transferred again, the execution of the instruction is performed again on the local machine L.
Will be done above. Flexible processing on a distributed system is realized by the remote programming as described above.

In such remote programming, if the interpretation execution means and the agent management means are configured in accordance with the hardware and OS specific to each machine while using instructions and internal information common to each machine, Compatibility is realized between machines having different configurations. With such a configuration, the above-described flexible correspondence can be achieved, for example, instructions can be moved and executed in a computer system having different operating systems and hardware.

On the other hand, as another conventional technique for performing processing over a plurality of nodes on a network, the following is known (reference: Oren Etzioni a).
nd Daniel Weld "A Softbot-Based Interface to the I
nternet "(Communications of ACM).
The processing is performed over a plurality of machines using a normal network function such as ftp for transferring a file and telnet for realizing a virtual terminal function for remote login. And based on the information collected during the operation,
The software automatically uses each function in a trial and error manner and flexibly performs planning according to the situation, thereby selecting a function corresponding to a change in the configuration of a file or the like.

For example, when a target function is transferred to another node, an attempt to access the function at the node before the transfer fails, so that planning is performed on the original machine (node) and the access destination is changed to the second one. Change to a candidate and access again. According to this technique, a flexible operation can be performed according to the state at each point in the system. In this case, use telnet or ftp within a range where compatibility is known in advance.

An agent having the above-described movement function is generally called a mobile agent.
As the most practical agent technology,
In recent years, it has received special attention. However, the biggest concern in practical use is the security problem. In other words, it has been pointed out that mobile agents do not satisfy many of the security assumptions assumed in conventional distributed systems (reference: [3] David M. Chess. Se
curity issues in mobile code systems. [10] Giovanni
Vigna, editor. Moblie Agents and Security, LNCS 1
419. SpringerVerlag, 1998., pp. 1-14.) Therefore, specific security and safety measures are required. Here, security is mainly to protect the system, particularly nodes, from unfair behavior, and safety is to ensure stable operation of the system against a failure that occurs mainly by accident. In addition, these security and safety are collectively referred to as node security. Further, from these viewpoints, specifically, the following problems must be solved. (1) Attacks on agents Such attacks include unauthorized access by malicious third parties and malicious hosts on the network,
That is, illegal reading / writing can be considered. (2) Attacks on hosts by malicious agents Such attacks include unauthorized access, waste of resources, and unusable attacks that stop host functions (Den
ial of Service, DoS). (3) Attacks on the entire network by a malicious agent Such attacks include spoofing using authentication information of another person, replay of repeatedly sending a duplicate of the agent, and the like.

[0022] To cope with the problem of security and safety of the mobile agent as described above, countermeasures as shown in FIG. 26 are currently proposed. Among them, the black box method is a method of forming a black box by composing information inside the agent in a complicated format peculiar to the outside (Ref: [8] Tomas Sander
and Christian F. Tschudin. Protecting mobile agen
ts against malicioushosts. ([10] Giovanni Vigna,
editor. Moblie Agents and Security, LNCS1419. Spri
nger Verlag, 1998., pp. 44-60.), [4] Fritz Hohl.
Time limitedblackbox security; protecting mobile a
gents from malicious hosts. (ibid. [10] pp. 92-11
3.)).

Also, the dummy data mixing is a method in which meaningless information is mixed with information inside the agent so that it is not possible to externally know which part of the information that is truly meaningful. References: [9] Giovanni Vig
na. Cryptographic traces for mobile agents.
[10] pp. 137-153.)).

[0024] Agent authentication is a method of preventing the activity of an unauthorized agent by giving a predetermined authentication to an agent of a correct feature (references: [1] Shimshon Berkovits, Joshua D. Guttman, and
Vipin Swarup.Authentication for mobile agents.
(Id. [10] pp. 114-136.). In addition, access authority control is a method of giving access authority to a host only to the correct agent (Reference: [7] John K. Ousterho
ut, Jacob Y. Levy, and Brent B. Welch. The Safe-Tc
l security model. (Id. [10] pp. 217-234.) Also,
Safety verification is a method for verifying the safety of agents and their actions (Ref: [5] George C. Necula
and Peter Lee. Safe, untrusted agents using proof-
carrying code. (ibid. [10] pp. 61-91.).

[0025]

However, the prior art as described above has the following problems.
First, a remote programming method (Japanese Patent Laid-Open No.
In 182174), since the user has to describe all the operation sequences of the agent as instructions, the programming work is complicated and the flexibility of the agent is limited. Also, in order to respond to changes in software components such as the destination of the agent by the go operation and the node name (identifier in the network) of the machine on which the component to be used exists, such a change is required. Although they need to be captured, no means has been provided for responding to such changes. In addition, to respond to changes in components,
Although it is necessary to change the instruction according to the change, conventionally, the machine name of the access destination is specifically specified, so even if the purpose can not be achieved without changing the access destination, the instruction can be changed on the spot. It was impossible to change. For this reason, a technology that flexibly responds to changes in the components has been required. In particular,
Since the change is more frequent in a large-scale network such as an open network, it has been strongly required to respond to the change.

In the method of Etzioni et al., The local machine and the remote machine need to keep accessing each other during the processing and exchange information continuously. For this reason, if a line failure occurs during the processing and the access route is disconnected, normal processing cannot be continued.
There was a problem. In addition, when it is necessary to change the processing content by carefully referring to the content of information at the remote node, to access the information of the remote node several times, or when some real-time processing is required In some cases, it is more efficient to perform information processing as a process on a remote machine. Further, when implementing such information processing, it is desirable to prevent harmful behavior such as the agent overloading the node, that is, the host as a result, even if the agent is not malicious.

The present invention has been proposed in order to solve the above-mentioned problems of the prior art. The purpose of the present invention is to allow an agent to operate based on a plan or to move between nodes so as to avoid environmental changes. This is to prevent harmful behavior such as an agent overloading a host by flexibly responding and matching a plan with a predetermined constraint. Another object of the present invention is to modify a plan that does not satisfy the constraint so as to meet the constraint,
It is also to ensure that the agent continues to work.

Another object of the present invention is to secure writing of an important file while maintaining a write allowance in a process of writing a file to a node. Another object of the present invention is to improve the possibility of writing a new file with a high priority to a node by deleting a file with a low priority. Further, an object of the third embodiment is to facilitate the flexible processing by designating in advance how to calculate the priority for each file.

Further, another object of the present invention is to divide a node into a plurality of fields corresponding to the purpose of information processing and the type of agent so as to make plan creation more efficient. Another object of the present invention is to apply a modification method suitable for an agent by carrying information on how to modify a plan even when the agent moves between nodes. Further, another object of the present invention is to attach a precondition presupposed to a movement command, thereby facilitating identification of a cause of a movement failure and coping with the failure.

[0030]

According to one aspect of the present invention, there is provided an information processing system in which an agent which is an execution entity of software operates on a node connected to a network to perform information processing. In the processing device, first storage means for storing first information representing a state of a component used for accessing a component arranged in the node, and a behavior of the execution subject are defined. Second storage means for storing second information; means for creating a plan to be executed by an agent based on the first and second information to achieve a given purpose; Storage means for storing third information representing constraints that the plan must satisfy for maintenance of the plan, and means for determining whether the plan satisfies the constraints Means for executing the plan and moving the agent between nodes with respect to the plan determined to satisfy the constraint, wherein the plan is created and determined even at the destination node. It is characterized by having been done. The invention according to claim 6 is an information processing method in which the invention according to claim 1 is viewed from the viewpoint of a method, in which an agent, which is an execution entity on software, operates on a node connected to a network. A step of storing first information representing a state of a component used for accessing a component arranged in the node, and storing second information defining behavior of the execution subject. Creating a plan to be executed by the agent to achieve a given purpose based on the first and second information; and Storing third information representing a constraint that must be satisfied; determining whether a plan satisfies the constraint; For plus and the determined plan, comprises the steps for realizing the movement between the node is executed and the agent plans, even in the destination node, and performs the creation and decision plan. Claim 1
According to a first aspect of the present invention, the inventions of the first and sixth aspects are viewed from the viewpoint of a recording medium on which software of a computer is recorded. In a recording medium on which information processing software for performing information processing by operating on the above is recorded, the software informs the computer of a state of a component used for accessing a component arranged in the node. The first information to be expressed is stored, the second information defining the behavior of the execution subject is stored, and an agent is executed based on the first and second information to achieve a given purpose. Third information representing the constraints that the plan must satisfy for node preservation. Is stored, and it is determined whether or not the plan satisfies the constraint. For the plan determined to satisfy the constraint, execution of the plan and movement of the agent between the nodes are realized. And a determination is made. According to the first, sixth, and eleventh aspects of the present invention, the configuration such as which node on the network contains each component such as a file is stored as first information, and the agent generates the configuration based on the first information. According to the plan, various processes including movement between nodes and re-planning at the destination are performed. Therefore, there is no need for the user to describe the operation sequence of the agent, and there is no need to continue exchanging information between nodes. In addition, a change in the configuration such as a file transfer between nodes can be reflected in the behavior of the agent by updating the first information accordingly, and it is possible to cope with an unexpected change in the configuration or situation. In particular, when an agent moves to another node to generate and execute a plan, the plan is executed only when it is determined that the plan satisfies the constraints for node integrity, so harmful behavior such as waste of system resources Is prevented in advance, and the security and safety of the node and the entire system are guaranteed. If the plan does not satisfy the constraints, modify the plan by regenerating the plan,
It may be possible to cancel the plan generation, move to another node, and redo the plan generation using the information stored in the destination node.

According to a second aspect of the present invention, in the information processing apparatus according to the first aspect, a fourth storage means for storing fourth information indicating how to generate a plan satisfying the constraint. Means for correcting the plan based on the fourth information when it is determined that the plan does not satisfy the constraint. According to a seventh aspect of the present invention, the second aspect of the present invention is viewed from the viewpoint of a method, and in the information processing method according to the sixth aspect, a fourth method representing how to generate a plan satisfying the constraint.
And a step of correcting the plan based on the fourth information when it is determined that the plan does not satisfy the constraint. According to a twelfth aspect of the present invention, the inventions of the second and seventh aspects are viewed from the viewpoint of a recording medium on which computer software is recorded. Causes the computer to store fourth information indicating how to generate a plan that satisfies the constraint, and when it is determined that the plan does not satisfy the constraint, based on the fourth information, It is characterized in that the plan is modified. According to the second, seventh and twelfth aspects of the present invention, the plan that does not satisfy the restrictions is corrected by re-planning or the like, so that not only security and safety is ensured but also continuation of the activity of the agent is ensured.

According to a third aspect of the present invention, in the information processing apparatus according to the second aspect, at least one of the nodes includes a plurality of fields that are active areas of an agent, and at least one of the first to fourth information items. One is stored for each field. According to the third aspect of the present invention, the agent moves to the field corresponding to the purpose of the information processing and the type of the agent, and only the information of the field is used in the plan creation. Is made more efficient. In particular,
According to the third aspect of the present invention, since the third information and the fourth information relating to the modification of the constraint and the plan can be set for each field, security safety suitable for each field is ensured.

According to a fourth aspect of the present invention, in the information processing apparatus according to the second or third aspect, the agent carries the unique fourth information even when moving between nodes. According to the fourth aspect of the present invention, each agent carries the unique fourth information even when moving between nodes, and the destination node also uses this fourth information to modify the plan. It is possible to apply an optimal plan modification method according to the purpose and state.

According to a fifth aspect of the present invention, in the information processing apparatus according to any one of the first to fourth aspects, the means for creating the plan includes a move instruction for moving an agent between nodes as part of the plan. Alternatively, it is characterized in that, when creating another command, a precondition as a premise of the command is attached to the movement command or the other command. According to the fifth aspect of the present invention, the precondition is attached to the movement command as a basis. If the movement based on the movement command fails, the preconditions premised on the command may not have been satisfied. This precondition is
Since it is attached to the movement instruction, it can be easily found by referring to the movement instruction. For this reason, the cause of the movement failure is specified, and handling of the failure becomes easy.

According to an eighth aspect of the present invention, in the information processing method according to the seventh aspect of the present invention for writing one or more files to a node, information indicating which file should be written to the node, and the size of each file And the information indicating the priority between the files, the third information indicates the restriction on the allowable value of the amount of information that can be written to the node, and the fourth information indicates the lower priority. The plan is modified by excluding the file from the writing target. According to the eighth aspect of the present invention, it is determined whether or not the amount of information after writing does not exceed an allowable value for a plan for writing a file to a node. For this reason, in posting an advertisement document, it is possible to secure writing of an important file while avoiding a problem that a file exceeding an allowable amount is written to a node.

According to a ninth aspect of the present invention, in the information processing method according to the eighth aspect, the fourth information includes, in the modification of the plan, a file having the lower priority among the files already written in the node. It is characterized in that it represents deletion. According to the ninth aspect of the present invention, when a file to be written in the plan does not fall within the allowable value of the node, a file having a low priority among the files already written in the node is deleted from the plan, so that a file with a high priority is deleted. The possibility of writing new files to the node is improved.

According to a tenth aspect of the present invention, in the information processing method according to the eighth or ninth aspect, information indicating how to calculate the priority order for each file is used. According to the tenth aspect, it is possible to specify in advance how to calculate the priority of each file based on information such as the importance of each file and the depth of the relationship between the file and the node. Becomes easier.

[0038]

Embodiments of the present invention (hereinafter referred to as "embodiments") will be described below with reference to the drawings. Note that the following embodiments are based on a distributed environment using a network including a plurality of nodes. here,
"Network" means a general computer-to-computer connection, specifically, the Internet, telephone lines,
And so on. “Node” is a unit of movement of an agent. Basically, one node is assumed on one host, that is, one computer, but a plurality of nodes may exist. The “distributed environment” is an environment in which there are a plurality of computers connected via a network, and the information held by each computer is different.

Each of the following embodiments is realized by controlling a CPU by a program on a computer. In this case, various modes of realization are conceivable. Therefore, in the following description, the present device will be described as a virtual circuit block such as “「 unit ”corresponding to each function of the present device. The CPU realizes the operation of each virtual circuit block while using various hardware resources of the computer as specified by the program.

As a typical example of hardware resources, a CPU
Through a bus and an input / output control circuit, a memory including a storage element such as a RAM, an auxiliary storage device such as a hard disk drive, a mouse or a keyboard as an input device,
It is conceivable to connect a display device or a printer as an output device. The computer is connected to a network via a network connection device. However, these hardware resources are merely examples, and other various devices that can achieve the purpose of storing, inputting, and outputting information can be used.

[1. First Embodiment] First, an object of a first embodiment is to provide an information processing apparatus that flexibly responds to changes in software components, assures system security and safety, and has excellent fault tolerance against line failure. It is to provide. Another object of the first embodiment is to provide an information processing apparatus and an information processing method that can be operated flexibly. Another object of the present embodiment is to provide an information processing apparatus and an information processing method with excellent processing efficiency.

Another object of the first embodiment is to prevent a harmful behavior such as an agent overloading a host by matching a plan with a predetermined constraint. That is, in the first embodiment, an intelligent network agent Plangent (reference: [6] Akih) is intended to be a development base for application programs using a wide open network environment.
iko Ohsuga, Yasuo Nagai, Yutaka Irie, Masanori Hat
tori, and Shinichi Honiden.Plangent: Anapproach
to making mobile agents intelligent.IEEE Internet
Computing ,, Vol.1, No. 4, pp. 50-57, July-August 1
997.), its security and safety functions will be described in detail. In particular, we show that Plangent can respond to security safety against behaviors that are harmful to hosts by autonomous agents, which was insufficient until now.

That is, with the development of a wide-area open network environment such as the Internet, the demand for a distributed system that changes rapidly and is given a variety of demands is increasing. Agents (see [2] Jeffrey Bradshaw. Software Agents. AAAI Pr.
ess / The MIT Press, 1997.). The agent is software that responds to changes in situations and various requests due to features such as autonomy, mobility, intelligence, coordination, and responsiveness. Plangent is an intelligent network agent system developed to answer such demands.

That is, the Plangent agent has a planning function, a plan execution function, a replanning function, and a network movement function. Here, the planning is a function for drafting an action plan for achieving the user's request, the plan execution is a function for executing the action plan thus formulated, and the re-planning function is a function for when the plan execution fails. This is the function to regenerate the plan. Plangent agents use these features to:
It realizes agent autonomy in the sense that it can respond flexibly to changes in the situation. The move function is a function of moving to a necessary place on the network and continuing work.

On the other hand, in order to make a mobile agent in an open network environment more practical, an agent that can flexibly respond to unexpected situation changes that frequently occur on such a network. Autonomy is also important. However, if such an autonomous agent runs on another host on the network, the agent may autonomously behave in ways that developers and callers cannot predict.
Even a maliciously authenticated agent can take the following harmful behavior. (1) Behavior similar to that of launching a resource waste or unusable attack described in the related art on an operation host. (2) Behavior such as execution of an operation that causes a fatal error, or an inability to operate halfway, such as the host being stopped during operation of the agent.

Therefore, in the autonomous agent, sufficient security cannot be ensured in the conventional framework. Therefore, comprehensive security and safety measures, including assurance that such harmful behavior does not occur, are required. However, security and safety measures from such a viewpoint have not been studied so far.

Therefore, in the first embodiment, Plangent proposes a countermeasure against a security / safety problem caused by agent autonomy by adding a constraint processing function to a planning function. Also, the first
Another purpose of the embodiment is to modify the plan that does not satisfy the constraint so as to conform to the constraint, thereby ensuring the continuation of the activity of the agent. In the third embodiment, in a process of writing a file to a node, writing of an important file is secured while observing an allowable write value.

That is, in the first embodiment, the requirements related to security and safety in each host, such as the computational resources and computational power of the host, are described as constraints, and the agent that has moved to the host, when generating behavior by planning, Then, it is determined whether or not the constraint according to the security / safety requirement is satisfied, and if the constraint is violated, a behavior is generated such that the constraint is not violated during execution. As a result, the agent satisfies the security and safety requirements described as constraints, thereby preventing harmful behaviors equivalent to resource waste and unusable attacks on the host.

[1-1. Configuration] [1-1-1. Hardware Configuration] FIG. 1 is a functional block diagram showing the configuration of the present embodiment. As shown in this figure, in the first embodiment, a plurality of nodes including nodes L and R are connected by a network N. Here, a node L where a request description is input, an agent is generated, and processing is started is called a local machine, and a node R to which the agent moves from the local machine is called a remote machine. The components of the software used for the information processing are distributed and arranged in the plurality of nodes, and the information processing is performed by an agent, which is an execution entity of the software, operating on one of the nodes.
Further, the first embodiment is configured such that each agent creates a plan, makes a determination, and creates a necessary plan even at a destination node.

FIG. 1 shows the configuration of the local machine L as a representative of the configuration, assuming that the nodes L and R have the same configuration. Also, in FIG. 1, a state in which the following functions are realized by controlling hardware such as the memory 101, the CPU 102, and the auxiliary storage device 103 described above by the information processing software. Is shown.

That is, first, each of the nodes L and R stores a local information storage unit 1 for storing local information (corresponding to the first information) used for accessing a component.
(1L and 1R, hereinafter the same. Corresponding to the first storage means) and an updating unit 2 for updating the stored local information. In addition, each node L, R
Are an agent information storage unit 3 for storing agent information (corresponding to the second information) and an input / output unit 4 for performing various input / output operations. (Corresponding to the input means for inputting a request description for information processing). The agent information is information on the behavior of the agent, and is sequentially updated according to the behavior of the agent itself.

Each of the nodes L and R generates a plan representing an action to be taken by an agent to satisfy the input request description as a set of a plurality of actions based on the agent information and the local information. It has a generation unit 5 (corresponding to the generation unit). The actions included in the plan generated by the plan generating unit 5 include a go action (corresponding to the first action) for realizing the movement of the agent between nodes as necessary.

Each of the nodes L and R is a plan execution unit 6 (corresponding to the execution means) for realizing the operation of the agent on each of the nodes L and R based on each action in the generated plan. And an agent management unit 7 (corresponding to the management means) for moving an agent between nodes based on a go action in a plan. Note that the agent management unit 7 has a function as determination means (claim 4) for determining the generated plan.

Each of the nodes L and R is stored in the third storage unit 8.
A determination unit 9, a fourth storage unit 10, a correction unit 11,
It has. The third storage unit 8 is a third storage unit for storing third information indicating a constraint that must be satisfied by the plan for maintaining the node. In this case, the security means security. The concept includes both safety and safety. That is, the constraint referred to here is a constraint that should be satisfied by the plan so that the agent does not take harmful behavior to the node, and the third information is information representing such a constraint.

The determining unit 9 determines whether or not the plan satisfies the constraint during or after the generation of the plan. The plan executing unit 6 determines whether the plan determined to satisfy the constraint is an agent. Is configured to execute the plan including the movement between the nodes.

The fourth storage unit 10 stores fourth information (referred to as constraint satisfaction meta-knowledge) indicating how to generate a plan satisfying the constraint. It is. In other words, constraint satisfaction meta-knowledge is the knowledge used to modify a plan so that if an agent attempts to execute a plan that does not satisfy the security-related constraints, the agent modifies the plan so that the constraints are satisfied. is there.

When it is determined that the plan does not satisfy the constraint, the modifying unit 11 modifies the plan based on the constraint satisfaction meta-knowledge stored in the fourth storage unit 10 or changes the constraint. This is a means for obtaining information that there is no plan to satisfy.

The main information used in this embodiment will be described below. [1-1-2. Agent information ... second information] The agent information is information for controlling the behavior of the agent and various information operated by the behavior. As the agent information, specifically, a set of actions (hereinafter referred to as “action set”), information on each action included in the set (hereinafter referred to as “action information”), and constraints on safety (hereinafter referred to as “safety set”) conditions"
) And a causal link (corresponding to the information indicating the causal relationship). First, the action set is a list of a set of actions constituting the plan being generated, and the action is a unit of action that the agent can take.

Each action has action information. The action information includes an action description indicating an action name and an argument (parameter), a precondition indicating a precondition for enabling the action to be executed, and a postcondition indicating the content of a state change due to execution. Or a list of terms.

The security condition is a condition indicating a restriction on an execution order between actions for each action in the action set, and is represented by a list of pairs of action descriptions. In other words, each pair constituting the security condition expresses a constraint that the first element should be executed before the second element. The order in the list of action sets and the actual execution order are irrelevant, and the execution order is only limited by this security condition.

The causal link is information indicating a causal relationship such that another action can be executed according to the fact that one action is executed for each action in the action set, and the action description is established by the action. It is expressed as a list of three sets of terms that represent the facts to be performed and action descriptions that can be executed when the facts are established.

In the following, a first example of searching for a given character string from a file and a second example of writing a file to a storage device of a node in consideration of the amount of information of the file will be described.
The first embodiment will be described with reference to two examples of the above.

First, in the first example, an example of the action information described above is shown below. Action description: grep (File, Keyword) Precondition: [file-exists (File)] Postcondition: [add (include (File, Keyword))] In this example, the action description "grep (File, Keyword)"
Searches for a file named "File" in the operation named "grep" for the string "Keyword", and if it is included, implements the post-condition.
Represents the operation. The pre-condition represents a condition that must be satisfied when executing the action. The precondition "file-exists (File)" in this example represents the fact that a file named "File" exists in the same format as the state description described above.

The post condition generally indicates a fact that occurs by executing an action. In this example, the post condition occurs only when a character string is included in a file. In the postcondition "add (include (File, Keyword))" of this example, "include (F
ile, Keyword) "represents the fact that the file named" File "contains the string Keyword." add () "refers to the fact described in parentheses (here," include (File, Keywor
d) "is added as agent knowledge.
On the other hand, the operation of deleting knowledge is expressed as "del ()".

Further, an example of the action description in the above-described second example is shown. Action description: write (File) Precondition: [to-write (File), size (File, Size), consu
med-space (Space)] Postcondition: [del (consumed-space (Space)), add (written
(File)), add (consumed-space (Space + Size))] This example relates to the process of writing a file to the storage device of the node and the amount of information of the file. More specifically, the action description “write (File)” is an operation named “write” and represents an operation of writing a file named “File” into the storage device of the node. In the precondition of this action description, "to-write (File)" is
Indicates that the file "File" should be written to the node. "Size (File, Size)" is the file
"File" indicates that the amount of information is "Size", and "consu
med-space (Space) "already has" Sp
ace "has been written. In the post condition of this action description," written (File) "
Indicates that the file "File" has already been written.

[1-1-3. Local information ... first information] The local information storage unit 2 stores local information. The local information in the present embodiment is information for accessing a component, and is represented by a symbol string called a term. In the present embodiment, it is assumed that a state description shown in the following example is stored in the local information storage unit 2. It should be noted that the state description is information indicating some fact regarding the components of the software. maybe (file-exists (file1) at node1) In this example, "maybe ()" indicates that the fact described in parentheses has not been confirmed. Also, "file-exists (fil
e1) indicates that there is a file with the file name "file1", and "at node1" after it is "node1"
This indicates that the above-mentioned fact (the existence of file file1) is satisfied on a machine having the node name of If the state description is "maybe ()", the above fact (machine node1
The existence of the file file1) in the machine node
Need to go to 1 to confirm. Here, the node name
node1 is the node name of the remote machine R.

It should be noted that such updating of the local information is as follows.
For example, a system administrator can manually update information when a component is changed in each machine. In this way, flexible operation is possible by adjusting the input content according to specific circumstances.

The local information can be automatically updated by a program by referring to a file list or the like representing a configuration in the network.
With this configuration, the detection of the change and the update of the local information are automatically performed, so that the labor of manually inputting the information can be omitted, and the processing can be made more efficient.

It is conceivable that the above-described agent information and local information are stored in the form of a character string text as described above. However, if necessary, other internal formats such as replacing reserved words with codes are used. Can also be stored.

In the second example described above, an example of local information stored in a certain node 0 is shown.

Maybe (to-write (file1) at node1) maybe (to-write (file2) at node1) In this example, "to-write (File)" should write the file "File" to the node. It means that there is.

[1-1-4. Third Information and Fourth Information] In addition, the third information indicating the constraint that must be satisfied by the plan and the constraint satisfaction meta-knowledge, that is, the fourth information, include the local information of the node and the movement of the agent as the agent moves. Prepare in the form of the agent information to be transported.

For example, in the second example described above,
It is conceivable to add the following knowledge as agent information. size (file1, 100) size (file2, 150) prefer (written (file1), written (file2)) With the knowledge of this last line, goal "written (file1)" takes precedence over goal "written (file2)" Represents the constraint satisfaction meta-knowledge.

In the second example described above, for example, it is assumed that local information of a certain node node1 has the following knowledge. to-write (File) consumed-space (0) ss-constraint ((consumed-space (Space), Space <12
0]) Here, the second information “consumed-space (0)” is security / safety constraint information indicating that the upper limit of the amount of information that can be written is 120.

[1-2. Operation and Effect] In the present embodiment having the above configuration, information processing is performed as follows.

[1-2-1. Input of request description]
4 shows a flowchart of a processing procedure of information processing according to the present embodiment. First, a user inputs a description of a state to be achieved by information processing as a request description from the input / output unit 1 (step 201). The input request description is stored in the agent information storage unit 3. Here, the request description is 1
It consists of one or more terms. An example of the request description is shown below. file-exists (File) at Node include-keyword (File, patent) The first line of this example, "file-exists (File) at Node", finds the file named File on the machine named Node. Represents a request. The second line is
Requires that the File contains the keyword patent. Therefore, this request description represents a request to search the network for a file containing the keyword "patent" and specify the file name and the node name.

[1-2-2. Initialization] Next, the agent management section 7 performs an initialization process (step 202). That is, the following pieces of information are separately stored as an action set, a security condition, and a causal link in the agent information storage unit 3. Action set: [* start *, * end *] Security condition: [(* start *, * end *)] Causal link: [] (empty list) Further, the following information is stored in the agent information storage unit 5: Add and store as action information. First, a list of the initial states other than the condition represented by "maybe ()" (called the "maybe condition") is defined as the post condition of the action having the action name "* start *".

In the initial state, “maybe (cond at n
ode) "(cond and node mean concrete conditions and node names, respectively), and add the following action information: Action name: go (node) Precondition: [] Post-condition: [add (cond at node)] In other words, define a go action that uses the condition after removing the may as a post-condition. This means that an action to move to a specific node is added to the action set.

For example, in the present embodiment, the following action information is added.

Action name: * start * Precondition: [] Postcondition: [] Action name: go (node1) Precondition: [] Postcondition: [add (file-exists (File) at node1)] Action name: * end * Precondition: [(file_exists (File) at Node), include-key
word (File, patent)] (same as requirement description) Postcondition: []

[1-2-3. Generation of Plan] Subsequently, the plan generation unit 5 generates a plan for satisfying the requirement description (step 203). Plan generation is
This is performed by updating the agent information while referring to the local information, and the updated agent information becomes a plan. Except for the part related to the transfer of the agent, the procedure for generating the plan is performed by a conventionally known planning technique (Reference 1: Sekio Osuka, edited by Encyclopedia of Artificial Intelligence, pages 979 to 988). This planning is to create an action plan for an agent such as a robot having the ability to change the outside world to achieve a given goal. Inputs for planning are the initial state of the outside world, various actions that change the outside world, and one or more goals.

The planning procedure in this embodiment is shown in the flowchart of FIG. First, it is checked whether or not there is an unachieved goal (step 301). Here, the unachieved goal is defined as a condition that is not recorded as a fact that is established in the causal link among the preconditions of each action constituting the action set. Here is a list of those represented by. In the present embodiment, since the causal link is initially empty, two preconditions of the action "* end *" are unachieved goals.

If there is no unachieved goal, the plan generation is terminated.
One subgoal is selected (step 302). In the present embodiment, for example, “file-exists (File) at Node” is selected as a subgoal. Next, in step 302, for the selected subgoal, actions that achieve the subgoal under the post condition are listed.

Here, the condition that the sub-goal is achieved is as follows.
By substituting an appropriate term for the variable of the condition, it is possible to match with the subgoal,
More specifically, it means an action having a post-condition in which the pre-condition of the selected subgoal matches an element other than the variable. For example, in the present embodiment, the action "go (node
1) "only.

Then, it is determined whether at least one action has been enumerated (step 304). If the action cannot be enumerated, subgoal selection is performed again as so-called backtrack processing (step 302).

Then, one of the listed actions is selected (step 305), and for the selected action,
If the preconditions of other actions are impaired, the selected actions are added to the causal link according to the conditions of the subgoal. In addition, if the precondition of another action is impaired and a safety condition can be added to prevent the precondition from being impaired before the execution of the other action, the selected action is added to the subgoal. The security condition is added to the causal link according to the condition.

These processes are specifically performed as follows. First, the causal link and the unachieved goal are updated based on the action information of the action (step 30).
6). To update the causal link, the above-mentioned substitution is performed on the elements (action description, pre-post condition and post-condition) of the action information, and the set of the action description, the subgoal, and the action description of the action with the subgoal as the precondition is set as the causal link. By adding At the same time, the precondition of the action information is newly added to the unachieved goal. For example, in the present embodiment, the action "go (node
1) "and update the result, causal link and unachieved goal as follows. Causal link: [(go (node1), file-exists (File) at node
1, * end *)] Unachieved goal: [include-keyword (File, patent)]

[1-2-4. Detection of Threat] Next, in step 307, it is checked whether or not the selected action impairs the condition of another causal link, that is, the situation assumed by the other action (step 307). If it does, it is called a threat. In the present embodiment, the selected go action does not impair the condition. That is, the go action does not generally impair the condition, and in this case, there is no action that cannot be made by moving the node.

If a threat exists, it is determined whether or not security conditions for avoiding the threat can be updated (step 308). Here, the security condition can be updated in the following cases.

For example, for the set (action 1, condition, action 2) added to the causal link, the pair (action 1, action 2) can be added to the safety condition without contradiction.
If there is a threat, that is, if action 1 impairs condition 2 with respect to another causal link (action 3, condition 2, action 4), the pair (action 3, action 3
Action 1) or (action 4, action 1) can be added to the safety condition without contradiction.

If the security condition cannot be updated, the updated state of the causal link and the unachieved goal is returned to the state before the update (step 310), and the process from the selection of the action is performed again as a so-called backtrack. . If the security condition can be updated, the security condition is updated (addition of a pair) in step 309.

In the present embodiment, the pair "(go (node1), * end *)"
Can be added to the security condition without contradiction, so that the security condition as a result of the update is "[(go (node1), * end *), (* start *, * end *)]". Thereafter, the processing from step 301 is repeated again. In this way, by repeating the process while referring to the necessary local information, for each unachieved goal, an attempt is made to add all actions corresponding to the unachieved goal to the causal link. Will be.

That is, the action can be executed in a state where the precondition is satisfied, and as a result of the execution, the postcondition is generated. Therefore, the action for generating the target state as the post condition is connected to the target state by the causal link, and the action for generating the precondition of the connected action as the post condition is further connected. In this way, by repeating the connection in the reverse order of the execution order, an operation sequence for realizing the target state can be obtained. As described above, according to the present invention, since the plan can be generated in units of simple processing, the processing is made more efficient.

For example, in the second example described above, if a request description such as written (file1) at node1 written (file2) at node1 is given to a certain node node0, for example,
In this example, a plan [go (node1), write (file1), write (file2)] is generated.

[1-2-5. Update agent information)
In the present embodiment, after the end of the repetition procedure, the information stored in the agent information storage unit 3 changes as follows. Action set: [grep (File, patent), go (node1)] Safety condition: [(grep (File, patent), * end *), (go (node1),
* end *), (* start *, * end *)] Causal link: [(grep (File, patent), include (File, paten
t), * end *), (go (node1), file-exists (File) at node1, * e
nd *)] Unachieved goal list: [file-exists (File)] FIG. 4 shows a tree diagram (plan tree) representing the contents of this agent information.

[1-2-6. Determination of Plan Generation Success] When a plan is generated as described above (FIG. 2, step 20)
3) First, a determination is made as to whether the generation of the plan was successful (step 204, claim 4). At this time, if an unachieved goal exists and the action set is empty, the plan generation is determined to have failed. If there is no unachieved goal, it is determined that the generation was successful and the required description was achieved without executing the plan. If an unachieved goal exists and the action set is not empty, it is determined that the plan has been successfully generated and the plan needs to be executed.

In the case where the generation of the plan is successful and the request description has been achieved, and in the case where the generation of the plan itself has failed,
The agent outputs the fact to the user from the input / output unit 4 (step 205), and ends the entire procedure. When the agent moves from the original local machine L and the request description is achieved in the remote machine R or the generation of the plan fails, the agent returns to the local machine L and outputs information to that effect. As described above, in the present embodiment, the result of the plan generation is determined, and the processing according to the determination result can be selected, so that the processing is made more efficient.

[1-2-7. Judgment Regarding Restriction and Correction of Plan] As described above, when it is determined that the plan has been successfully generated, the determination unit 9 subsequently determines whether the generated plan satisfies the security safety constraint. Is determined (step 206). For example, in the second example described above, the agent first
As a result of creating and executing the plan [go (node1), write (file1), write (file2)] on ode0, the plan [write (file1), write (frile2)] is newly generated on the destination node node1. And And about this plan,
It is assumed that the determination unit 9 determines whether or not the security safety constraint is satisfied. In this case, the precondition consumed-space (0) is the result of executing this plan, and consumed-space (0 + 100 = 100) and consumed-space (100 + 150
= 250), which results in consumed-space (250), which is the above constraint ss-constraint ([consumed-space (Space), Space <12
0]) is not satisfied.

That is, if this plan is executed,
Information is written beyond the set upper limit of writing, which is a harmful behavior that wastes system resources.

As described above, when the determining unit 9 determines that the plan does not satisfy the constraint, the correcting unit 11
Using the meta-knowledge stored in the storage unit 10, the generation of a plan, for example, excluding the low-priority goal written (file2) is repeated (step 207). The resulting plan [write (file1)] becomes consumed-space (100) as a condition after the execution of the plan, and satisfies the above-mentioned constraint. If the plan does not satisfy the constraint, a message to that effect may be output.

[1-2-8. Execution of Plan] Subsequently, in execution of the plan, the plan executing unit 6 searches for an executable action other than the go action (step 206). Executable actions satisfy the preconditions according to the current state of the actions in the action set,
Also, it is not necessary to execute the safety condition later than other actions.

If there is an executable action other than the go action (steps 208 and 209), the action is executed (step 210), and the procedure from step 206 is executed again. When there is no executable action other than the go action, one go action is executed (step 211).

As described above, in this embodiment, an executable action other than the go action is executed prior to the execution of the go action, so that the process of transferring the agent to the original node again is minimized, and Is made more efficient.

In the example of this embodiment, when the execution of the plan is started, "g"
rep (File, patent) ". However, at this point, this action cannot be executed because the precondition has not been achieved, and consequently, there is no executable action other than the go action. Therefore, the action "g
o (node1) "is executed.

When the go action is interpreted and executed, the plan execution unit 6 notifies the agent management unit 7 of the interpretation, and the agent management unit 7 performs the following agent transfer processing.

[1-2-9. Transfer of Agent] When transferring an agent, a network is connected between an agent management unit 7L (hereinafter, referred to as “local side”) on the local machine side and an agent management unit 7R (hereinafter, referred to as “remote side”) on the remote machine side. Through N, the following procedure is executed. FIG. 5 is a flowchart showing a procedure for transferring an agent.

First, an agent acceptance request is transmitted from the local side to the remote side (step 50).
1). Upon receiving the request (step 50)
2) After making preparations for accepting the agent by setting a process for the agent (step 503), a notification of completion of preparation is transmitted to the local side (step 504).

When the local side receives the notification of the completion of preparation (step 505), it reads out the agent information in the agent information storage section 3 and transmits it to the remote side (step 506). (The transferred agent information includes the internal state of the agent at the time when the go action is interpreted and executed.) Upon receiving the agent information (step 507), the remote side stores the received agent information in the agent information storage unit 3. The information is stored (step 508), interpretation execution is started by notifying the plan execution unit 6 of that (step 509), and a notification that the agent acceptance has been successful is transmitted to the local side (step 510).

When the local side receives the notification of success (step 511), it deletes the agent process (step 512) and releases resources such as unnecessary memory to terminate the transfer of the agent.

In the example of this embodiment, it is assumed that the following information is stored in the local information storage unit 1 in the remote machine node1 after the transfer. file-exists (file1) Further, it is assumed that a file named file1 exists on the machine node1 and contains the character string patent. In this case, after moving to the machine node1, the agent executes the procedure of initialization to plan generation again. as a result,
The information stored in the agent information storage changes as follows. Action set: [grep (file1, patent)] Security condition: [(grep (file1, patent), * end *), (* start *, *
end *)] Causal link: [(* start *, file-exists (file1), grep (file
1, patent)), (grep (file1, patent), include (file1, paten
t), * end *)] Unachieved goal list: [] The plan generation succeeded, and the action grep (f
ile1, patent) will execute the plan successfully.
The agent returns to the local machine and outputs information to that effect to the user. FIG. 6 shows an output example of the execution result. In this example, the final goal 5 is displayed in the display window.
The execution result 501 is displayed together with the request description as “00”.

Even if the file file1 has been moved to another machine, "maybe (file-exists (file2)
If information such as "at node2)" is stored in the local information storage unit, the agent can be moved to machine node2 by replanning to achieve the purpose.
It can respond flexibly to changes in the environment.

[1-3. Effect] As described above, according to the first embodiment, the configuration such as which node on the network each component such as a file is stored in is stored as the first information, and the agent transmits this first information. Various processes including movement between nodes and replanning at the destination are performed in accordance with the plan generated based on. Therefore, there is no need for the user to describe the operation sequence of the agent, and there is no need to continue exchanging information between nodes. In addition, a change in the configuration such as a file transfer between nodes can be reflected in the behavior of the agent by updating the first information accordingly, and it is possible to cope with an unexpected change in the configuration or situation. In particular, when an agent moves to another node to generate and execute a plan, the plan is executed only when it is determined that the plan satisfies the constraints for node integrity, so harmful behavior such as waste of system resources Is prevented in advance, and the security and safety of the node and the entire system are guaranteed.
If the plan does not satisfy the constraints, modify the plan by regenerating the plan, cancel the plan generation, move to another node, and use the information stored in the destination node. It is possible to take measures such as redoing the plan generation.

In the first embodiment, a plan that does not satisfy the constraints is corrected by re-planning or the like.
Not only security and safety are guaranteed, but also the continuation of the agent's activity is ensured.

[2. Second Embodiment] The second embodiment has the same configuration and processing as the first embodiment described above.
It shows a more specific example. More specifically, an object of the second embodiment is to improve the possibility of writing a new file with a high priority to a node by deleting a file with a low priority. An object of the third embodiment is to facilitate flexible processing by designating in advance how to calculate the priority for each file.

[2-1. Specific Example in Second Embodiment]
In the second embodiment, as an example to which the present invention is applied, an advertisement agent that goes around an advertisement server, which is a node on a network, and registers advertisement information at each site will be described. That is, the setting of this example is as follows.

(1) First, when using an agent, it is assumed that there is a request to register as much information as possible in one round. Such a request occurs, for example, when an advertising agency wants to use an agent to post promotional documents for a plurality of customers on these sites.

(2) However, in general, in the case of an advertisement server, in the case of a user, that is, an agent, a write limit per sender is set. Accordingly, it is assumed that each user and agent must delete, from a less important one such as an old one, when the number of writes increases to some extent. It should be noted that the specific value of the writing restriction of each site is determined by each site independently.

(3) Since the advertisement server is open to the public, an unspecified number of users are targeted. Therefore, the write limit for each user is also
It needs to be changed as needed according to the number of users and the status of each user. Therefore, automatic management of the advertisement server is essential. In such a case, it is desired that the security and safety of the advertisement server, which is a node, is not infringed due to an administration error that causes an advertisement or the like to be written beyond the intended limit.

(4) Further, when the agent registers a plurality of documents, it is necessary to consider a difference in importance between the documents. In addition, each site has different characteristics depending on what kind of advertisements are to be posted, and it is assumed that the agent wants to advertise in consideration of such characteristics. Therefore,
It is necessary to decide how to deal with the writing restriction by also giving importance to these viewpoints.

In the present example, while fulfilling the above requirements, the processing relating to the planning and the restriction and the modification of the plan are performed, so that the posting / deletion of the advertisement document can be performed while observing the writing restriction of each site. By doing so, effective advertising activities will be conducted, and the specific procedures will be described below. In this procedure, first, the following initial settings are performed.

[2-2. Processing procedure in second embodiment] [2-2-1. Contents of Initial Setting] The following parameters are set in advance in the agent and each server. (1) The amount of information in each document for which the agent is responsible for advertising:
Let dqi be the document di (i = 1,..., L). (2) Importance of each document: Pi is assigned to document di. (3) Field relevance of each document: document di, target field fj
(J = 1,..., M) is drij. (4) Amount of publishable information per user of each server: sqk for server sk (k = 1,..., N). (5) Field relevance of each server: server sk, target field f
j is assumed to be srkj.

[2-2-2. Knowledge] In addition, the sender of the agent gives the following knowledge to the agent. (1) Action knowledge This action knowledge is knowledge about an action that can be performed by an agent, and specifically, a description of an action, a command for executing the action, a precondition indicating a situation in which the action can be executed, and an action execution This is a post condition that represents a situation that is satisfied later. For example, for the operation advertise (D) that describes document D, the preconditions may be such as consumed_space (X), size (D, S), not (advertised (D)), and these are the remaining This represents a condition that the possible information amount is X bytes, the size of the document D is S bytes, and the document D is not posted. In addition, post-conditions such as consumed_space (X + S) and advertised (D) can be considered. This is because the document D has been posted and the amount of information that can be posted has been posted in the previous X bytes. X + S, which is obtained by adding the size S of A description of such action knowledge in a character string is called an action description.

(2) Meta-Knowledge for Planning Control This meta-knowledge is used for re-planning (re-planning) when the constraint is not satisfied, that is, when the write limit is exceeded. Details will be described later.

(3) Further, the caller gives the request to the agent to the agent as a goal description in this case to post all the advertisement documents. In the second embodiment, a description “advertised (d)” is given for each document d.

[2-2-3. Procedure for server patrol and document posting] Based on the above information, the agent next performs a server patrol and document posting procedure as follows. 1. First, the agent determines a server that circulates and posts a document. Then, the following procedure is repeated each time the server moves to each of the traveling destination servers. 2. That is, when the agent moves to the server, the server performs an agent authentication procedure. 3. If this authentication procedure is successful, the server notifies the agent of the remaining publishable information amount. 4. The agent calculates whether or not all the documents to be posted fit in the notified amount of information that can be posted. As a result, if it fits, all documents are posted on that server and moved to the next server. On the other hand, if it does not fit,
A document posting / deletion procedure that fits in the amount of information that can be posted is generated as a plan that represents the operation of the agent.
Note that this plan is specifically realized by the agent determining the constraint and, if necessary, performing a replanning procedure to satisfy the constraint, as described in the first embodiment. I do. 5. As described above, when a plan that satisfies the constraint is obtained, the plan is executed and the server moves to the next server. More specifically, the procedure of processing related to constraints and planning is as follows.

[2-2-4. Procedures for processing related to constraints and planning] First, as described in detail in the first embodiment, the agent generates a plan by performing backward inference from a given goal (step 20).
3). That is, a plan for achieving the goal is generated by generating a chain from the post-condition to the pre-condition of the action knowledge. For example, if the example of the second embodiment is expressed in a simplified manner, it can be inferred that the operation of “posting of document d” may be executed in order to satisfy the goal of “document d is posted”. Do.

[0127] 2. After generating such a plan, the agent checks whether the generated plan satisfies the security and safety constraints (step 2).
06). In this example, specifically, it is checked whether or not the information amount is within the writing limit even after the execution of the plan, by calculating the total amount of information of the posted document in the case where the plan is executed.

Here, if the check succeeds, that is, if the plan satisfies the constraint, the procedure is terminated and the execution of the plan is started. If the check fails, that is, the plan does not satisfy the constraint. If so, replanning is performed according to the meta-knowledge (step 20).
7). Note that the meta-knowledge in the present example is that "the unimportant document and the previously published document with the minimum importance are deleted or not published. However, the deletion is performed first."
That is.

3. In the re-planning based on the meta-knowledge, the agent calculates the importance of the new publication-scheduled document and the document already published on the current server by the following formula. Here, the importance of the document di on the server sk is:

(Equation 1) And

[0130] 4. Further, based on the meta-knowledge, a plan is created in which the least important of the documents is set as follows. It repeats from the check of whether it is satisfied (step 206).

[2-2-5. Specific example of operation of agent] Next, more specific operation of the agent will be shown by numerical examples based on the following information. First, it is assumed that the following action description is given according to the grammar described above. Action description: advertise (Document) Precondition: [not (advertised (Document)), size (Documen
t, Size), consumed_space (Space)] Postcondition: [del (consumed_space (Space)), add (adverti
sed (Document)), del (not (advertised (Document))), add
(consumed_space (Space + Size))] Action description: delete (Document) Precondition: [advertised (Document), size (Document, Si)
ze), consumed_space (Space)] Postcondition: [del (consumed_space (Space)), del (adverti
sed (Document)), add (not (advertised (Document))), add
(consumed_space (Space-Size))] Further, it is assumed that the following knowledge is added as agent information. size (d1, 500) size (d2, 700) size (d3, 300) size (d4, 400) size (d5, 600) important (d1) = 8 important (d2) = 6 important (d3) = 10 important ( d4) = 3 important (d5) = 7 relevance (d1, f1) = 7 relevance (d2, f1) = 3 relevance (d3, f1) = 1 relevance (d4, f1) = 10 relevance (d5, f1) = 5 relevance (d1, f2) = 5 relevance (d2, f2) = 9 relevance (d3, f2) = 2 relevance (d4, f2) = 4 relevance (d5, f2) = 6 change_goal (advertised (Document), not (advertised) (D
ocument))):-min (server_important (Document)) where the last knowledge starting with "change_goal (" is the goal adv from the smallest "server_important"
Represents constraint satisfaction meta-knowledge of changing ertised to not (advertised).

Also, as local information of node0, maybe (not (advertised (d1) at node1)) maybe (not (advertised (d2) at node1)) maybe (not (advertised (d3) at node1)) maybe (advertised (d4) at node1) maybe (advertised (d5) at node1) and the required description is advertised (d1) at node1 advertised (d2) at node1 advertised (d3) at node1 advertised (d4) at node1 advertised (d5) Assume that at node1 is given. In this case, the agent first executes the plan [go (node1), advertise (d1), advertise (d2), advertis
e (d3)], and moves to node node1 as a result. The local information of the destination node node1 is as follows. not (advertised (d1) at node1) not (advertised (d2) at node1) not (advertised (d3) at node1) advertised (d4) at node1 advertised (d5) at node1 consumed_space (1000) server_important (Document) = important ( Document) *
(relevance (Document, f1) * 8 + relevance (Document, f1)
f2) * 5) ss-constraint ((consumed_space (Space), Spa
ce <2000]) At this node node1, the agent tries to publish three documents d1, d2 and d3. On the other hand, two documents d4 and d5 have already been posted on the server. Here, it is assumed that the information amount, the importance, and the degree of association with each field of each document are as shown in FIG. Also, the degree of relevance to each field f1 and f2 of the server is 8, 5 respectively,
The remaining information available to the caller of the agent is 1
Let it be 000 bytes.

In this case, the agent generates a plan [advertise (d1), advertise (d2), advertise (d3)] again after successful authentication at the server, and determines whether or not this plan satisfies the security and safety constraints. I do. Here, the total amount of information to be newly posted is 500 + 700 + 300 = 15.
00, but since the information amount of the already posted documents d4 and d5 is 1000 bytes in total, it becomes consumed_space (2500) as a condition after the execution of the plan. It can be seen that the total amount does not fall within the range of the allowed information amount. That is, it turns out that the plan generated here does not satisfy the above-mentioned restrictions. In other words, when you run this plan,
Information is written beyond the set upper limit of writing, which is a harmful behavior that wastes system resources.

Therefore, the modifying unit 11 shown in FIG. 1 uses the meta-knowledge, changes the goals in the order of importance, and repeats the plan generation. In this plan generation, first, the importance of each document is calculated as follows.

D1: 8 × (7 × 8 + 5 × 5) = 648 d2: 6 × (3 × 8 + 9 × 5) = 414 d3: 10 × (1 × 8 + 2 × 5) = 180 d4: 3 × (10 × 8 + 4) × 5) = 300 d5: 7 × (5 × 8 + 6 × 5) = 490 Therefore, each document is classified into d1, d5, d2,
d4 and d3. Therefore, d3, which is the least important,
, And the amount of newly posted information is 500 + 700 =
1200, but the remaining available information amount of 100
It still does not fit in 0 bytes. Therefore, when the next less important d4 is deleted, the amount of available information becomes 1000+
400 = 1400 bytes, and d1 and d2 can be posted. If a plan called [delete (d4), advertise (d1), advertise (d2)] is generated, this plan satisfies the constraints. For this reason, the agent deletes d4 according to the new plan, then lists d1 and d2, terminates the operation on this server, and moves to the next server.

[2-3. Effect of Second Embodiment] As described above, in the second embodiment, it is determined whether or not the amount of information after writing does not exceed an allowable value in a plan for writing a file to a node. The plan is modified by removing the post. For this reason, in posting an advertisement document, it is possible to secure writing of an important file while avoiding a problem that a file exceeding an allowable amount is written to a node.

In the second embodiment, when the file to be written in the plan does not fall within the allowable value of the node, the deletion of the file having the lower priority order among the files already written in the node is added to the plan. So
The possibility that a new file with a higher priority can be written to the node is improved.

In the second embodiment, how to calculate the priority of each file in advance is specified based on information such as the importance of each file and the depth of the relationship between the file and the node. Because it is possible, flexible processing becomes easy.

That is, in the past, in the case of the autonomous agent, the security safety against the eventual harmful behavior to the host was insufficient, but in the example described in the second embodiment, Performs processing such as judgment related to constraints and plan modification
An example of effectively realizing such a response by incorporating it into the planning mechanism in nt was presented. Thereby, when the agent autonomously generates and executes a plan for writing a document to the advertisement server using the planning mechanism, it is possible to guarantee that the safety requirement of writing restriction to the server is satisfied.

Also, the present invention as described above is
At the same time, it is possible to combine existing security and safety functions in the sense of preventing unauthorized access at the same time. In addition, the practical use and spread of Plangent can be promoted by solving other security and safety issues such as the inoperability of agents.

For example, to obtain an effect of preventing a malicious agent from attacking a host, for example,
By describing restrictions on access authority as security and safety restrictions, and by describing knowledge of operations related to access restrictions as local knowledge, unauthorized access can be prevented.

More specifically, for example, as a local operation knowledge, there is add (access_level (L)) as a precondition of the operation read (a_restricted_file), and access_level (L), L> 5 as a security safety constraint. This will prevent unauthorized access by agents with an access privilege level of 5 or less.

[3. Third Embodiment] The third embodiment more specifically shows the configuration and operation of an information processing apparatus having a configuration substantially the same as that of the first embodiment (FIG. 1). The plan creation is made more efficient by dividing the data into a plurality of fields corresponding to the types of agents and agents. In the third embodiment, information on how to modify a plan is carried around even when the agent moves between nodes, so that a modification method suitable for the agent is applied. Further, in the third embodiment, by attaching a precondition presupposed to the movement command, the cause of the movement failure can be easily specified and dealt with.

[3-1. Configuration] [3-1-1. Overall Configuration] The third embodiment is, like the first embodiment, an information processing apparatus that performs information processing by operating an agent that is an execution entity of software on a plurality of nodes connected to a network. FIG. 8 is a functional block diagram showing a configuration of each node connected to the network N in the third embodiment. As shown in this figure, each node includes a field knowledge base 20, a node knowledge base 12, a planner 13
Executor 14, Node Manager 15, Updater 1
6.

That is, first, each node has local information as first information to be used for accessing the components arranged in the node. The field knowledge base 20 and the node knowledge base 12, which are databases, first store the first information, and correspond to the local information storage means in the first embodiment. That is, the local information includes a portion divided into a plurality of fields corresponding to each type of agent and a portion unique to the node, and is stored in the field knowledge base 20 and the node knowledge base 12, respectively. A field is a group of information used only by agents of a particular type, ie, purpose or field.

In the third embodiment, each knowledge base 1
In addition to the above-mentioned local information, second information about actions that can be taken by the agent is stored in the information items 1 and 12. The planner 13 is a part for creating (planning) a plan to be executed by the agent (process) 17 to achieve a given purpose based on the first and second information. Corresponds to plan generation means.

The executing unit 14 executes the created plan, and corresponds to the plan executing means in the first embodiment. The node manager 15 is a part for realizing generation / deletion of the agent 17 and movement between nodes, and corresponds to the agent management unit in the first embodiment. The planner 3 and the executor 14 of each node execute a plan and create a necessary plan for an agent moved from another node.

The information represented by the first information relates to the software element on the node.
The status of the node, files and databases existing in the node, owned software, and the like. Also, the second information on the action is defined for each node.

The planner 13 is configured to create a plan for an agent based on information in a field corresponding to the agent. Also,
When the node manager 15 moves between nodes,
The agent is configured to move to a corresponding field in the destination node. In order to move the agent to a predetermined destination field, the field may be specified in a predetermined format, such as a parameter of the command, in the move command included in the plan.

The updating unit 16 is a part for correcting the information causing the failure when the planning, the execution of the plan or the movement based on the plan fails, and corresponds to the updating means in the first embodiment. I do.

The node uses a GUI (graphical user interface) application 18 as a user interface. Here, the user interface is software used by the user to directly monitor the state of the agent, and corresponds to the input / output unit in the first embodiment. Since the agent is an entity in software, the user needs software having a user interface in order to refer to and control the state of the agent.
The UI application 18 is used. Also,
Information on resource management such as memory for each node is stored in the node management information storage unit 19.

Further, in addition to the above-described configuration, the node includes a third storage unit 8 as shown in FIG.
, A fourth storage unit 10, and a correction unit 11.
In the third embodiment, the third storage unit 8,
Since the configurations and operations of the determination unit 9, the fourth storage unit 10, and the correction unit 11 are the same as those described in the first and second embodiments, the description will focus on specific configurations other than these and their operations. .

Here, FIG. 9 shows a concrete assumption of a node configuration used as an example in the third embodiment. In this example, an information processing apparatus in which three nodes X, node0, node1, and node2, are connected to a network N is assumed. Each node X has a field F named make, and other fields are omitted. That is, in the example of the node configuration in the third embodiment, for example, in software development by a plurality of people, a plurality of source files distributed and created on a network are accumulated in a specific node at a necessary time. In particular, some of the processes are extracted and described.

Note that, as shown in FIG.
Has information relating to a state or an action and fourth information for correcting a plan as information unique to the agent A, and this information is stored in a knowledge base D in the agent.
A. The agent A conveys such information even when moving between nodes, and uses the conveyed information for planning, plan modification, and the like.

[3-1-2. Schematic Configuration of Agent] An agent is a process generated on a node by a user of a system or another software using the present system by giving a goal. The node indicates a unit of movement of the agent, and is an abstract concept. It is generally assumed that one node exists for one host, but a plurality of nodes may exist for one host. The user gives the node a unique node name in the network. In this case, as the node name, it is possible to give the same name as a name given by an existing computer network naming method such as a URL. Also, the above “process”
A unit that executes software on a computer, and is managed by an operating system.

FIG. 10 shows an environment in which an agent is configured as a Plangent mobile agent, and is a conceptual diagram showing a state where nodes are divided into fields. Although what is actually divided into fields is the first to fourth information stored for each node,
These pieces of information have a role as a basis of the agent's activities such as plan creation and plan execution, that is, a place for activities.
Therefore, by dividing information on a node, a plurality of fields, which are “places” of agent activities, exist on the node.

The components of the environment configuration shown in the figure are a node X resident on the host H, a field F for dividing the inside of the node X, an agent A for moving the node X via the network N, and the like.

The purpose of such an agent is to satisfy a goal given in a predetermined expression form as a purpose of information processing. One example of a goal is to look for a particular file that might be on some other node and bring back a copy. For this purpose, the agent generates and executes a plan that satisfies the given goal. Agents can move to other nodes as needed to achieve the goal. The processes such as plan creation, plan execution, and movement between nodes by the agent are specifically realized by the planner 13, the executor 14, the node manager 15, and the like.

Then, the generated agent ultimately achieves the goal or cannot achieve the goal,
Either state is reached and disappears. The case where the goal is achieved is called normal termination of the agent, and the case where the goal cannot be achieved is called complete failure of the agent. At the time of extinction, a termination process is performed.

FIG. 11 is a state transition diagram illustrating a plurality of phases in the activity of the agent. That is,
Thereafter, the generated agent performs information processing while repeating three phases of a planning phase P, an execution phase E, and a movement phase M. Note that the planning phase P also includes processes such as a determination regarding a constraint for security and safety and a plan modification in the case of a constraint violation.

[3-1-3. Agent logical structure]
Next, FIG. 12 shows a logical structure of an agent in the third embodiment. That is, the agent has data such as an agent name, a field name of a corresponding field, and a possessed file. Note that the owned file is a file owned by the agent as a part of itself, and the agent that has moved to another node returns a copy of the file to the original node as an owned file, for example, the file shown as an example earlier Effective information collection is possible for the purpose of collection. The agent has the following other components in addition to the above components.

First, the goal stack S is a stack in which goals in execution are piled up in order to implement planning in a hierarchical manner. The goal stack is maintained as a set of goal script sets. The goal script set is a set of scripts of the plan for achieving the final goals and subgoals and each of those goals, and includes all scripts owned by the agent at that time.

The agent knowledge base DA is a knowledge base used by an agent together with a node knowledge base and a field knowledge base in planning. The “other” element in FIG. 12 includes, for example, execution information. The execution information is information such as an agent name, a field name, an execution position in a script, and a value of a variable used in the script. Further, as the information of “others”, information such as designation of a process at the time of termination may be considered. The specific data structure representing these pieces of information may vary depending on the phase of the agent. For example, it is stored in a memory on a computer as communication contents on a network during the movement phase, as a file structure in a storage medium during the execution phase, and as a data structure on a program during the planning phase.

The goal is represented by a stack structure because the goal given by the user generally has a hierarchical structure by planning. That is, the newly created subgoals need to be held hierarchically in the form of a stack inside the agent. FIG. 13 shows a data structure of a goal script set constituting the goal stack.

In this figure, a “goal” is a request given by a user who uses an agent or another software. With respect to any goal script set, a goal may be a subgoal. That is, the “subgoal” is a goal obtained by decomposing the conditions necessary to satisfy the goal initially given to the agent.

The subgoals that can be created in the third embodiment include two subgoals at the time of failure and at the time of planning.
The street is conceivable. The failed subgoal is a subgoal generated when execution of a specific command fails during execution of a script by an agent, in order to try to execute the command in another mode. In this case, for example, if the file location fails to be found at the first candidate node, the subgoal is to find the file at the second candidate node.

The planning subgoal is a subgoal included in the script as a result of normal planning. For example, in the case where the goal is to find a file and take it home, a subgoal is to find a file or move to another node for discovery.

The subgoal can further have a subgoal, and the goal has a hierarchical structure as a whole. The “goal stack” is a stack that is owned by an executing agent and manages a hierarchical goal structure. The agent hierarchically holds final goals and subgoals given at the time of generation.

[3-1-4. Node Manager] The part that manages the agent as described above is the node manager 15. The node manager is a module for managing nodes, and particularly performs processes such as generation of agents and movement of agents between nodes.
When performing such processing, the node manager communicates with the node managers of other nodes as necessary.
The interface in this communication is hereinafter referred to as an inter-node interface. In the third embodiment, the interface is implemented using a TCP port in the Internet protocol suite, and the name is referred to as a node port. Each node manager functions as a server on a respective port.

The node manager also communicates with the agent generated by the node manager. The interface in this communication is hereinafter referred to as a node-agent interface. In the third embodiment, a node-agent interface is implemented using a node port of the node manager, and the node manager side is a server and the agent process side is a client.

FIG. 14 is a diagram showing a configuration example for realizing node-to-agent communication and node-to-node communication with the node manager 15 at the center. Each node is provided with a monitor MN, which is a software module for outputting the state of the agent, and the node manager 15 transmits a monitor script as a display instruction to the monitor MN. Note that the name of the port in the third embodiment is referred to as a monitor port MP. The node manager side is a server port, and the monitor MN side is a client port. Hereinafter, unless otherwise specified, when simply referred to as a node port, it refers to a node port NP in the same node. The communication protocol in each communication port is composed of the following words separated by a predetermined predetermined delimiter.

First, the protocol of the inter-node interface according to the embodiment is shown in the table.

[Table 1]

Further, the table shows the protocol of the node-agent interface according to the embodiment.

[Table 2]

The node manager outputs a monitor script from a monitor port for monitoring the agent by the monitor. With respect to this communication port, a session is established from the monitor which is a client to the node manager which is a server. The monitor can receive the monitor script and update the user interface. The output content of the monitor script basically has the following format according to the access to the node / port.

[Table 3]

That is, the monitor receives a status report on the agent from the node manager in the form of a monitor script, and presents the status of the agent to the user. If the server-client relationship with the monitor is not established, the node manager does not output the monitor script. The procedures shown in the flowchart all assume that a connection with the monitor has been established. That is, when the connection is not established, it is needless to say that it is not necessary to perform communication according to the following protocol.

[3-1-5. Knowledge Base] The knowledge base is a database based on a declarative description method. Third
In the embodiment, more specifically, it refers to a set of facts in the Prolog language. Here, FIG. 15 is a conceptual block diagram showing the configuration of the knowledge base. As shown in this figure, there are two types of knowledge bases of the third embodiment, an action base D1 and an information base D2. The action base D1 is a set of actions that are essential in planning. The information base D2 is a knowledge base that stores an initial state of the system that is indispensable in planning, and any knowledge base can be updated by an action.

Action Base D1 and Information Base D2
Has an agent-specific part, a field-partitioned part, and a node-specific part, respectively.
Agent action base D1A, agent information base D2A, field action base D1F
And the field information base D2F, the node action base D1N, and the node information base D2N. The fields are portions corresponding to different purposes of the agent, and one field corresponds to an agent having a common purpose. By dividing the knowledge base into fields, it has the function of configuring a plurality of different knowledge bases in one node,
By using only necessary information for planning of one agent, there is an effect that planning is efficiently performed.

In general, in a knowledge expression, the existence of inconsistent descriptions causes semantic difficulties. The division of the knowledge base by the field has the effect of facilitating the smooth execution of the planning by the agent and the easy description of the action definition by making it easy to unify the semantic expressions for each field.

That is, for each of the action base and the information base, there are three types of knowledge bases: a knowledge base belonging to a node, a knowledge base belonging to a field, and a knowledge base belonging to an agent.

The third embodiment will be described using the term Prolog. For the Prolog language, see Leon Sterling,
Although there are many books such as The Art of Prolog by Ehud Shapiro, the Prolog language description in the third embodiment is described using only a standard description method. Prol
In the og language, names starting with an uppercase letter are variables, which are replaced by terms that are matching atoms or combinations of atoms.

In the following, an example will be used to show how an agent performs planning using information about other nodes, that is, may information from the viewpoint of a predetermined node, and how to behave in response to a changing network. Will be explained. maybe information can be implemented using the Prolog language. That is, of the information stored in the knowledge base,
Information of type maybe (maybe information) represents a supposed but unconfirmed fact. maybe is stored in the field information base or node information base.

On the other hand, the node manager in this system, that is, the agent management unit 7 in FIG.
It is configured to handle various types of agents corresponding to different fields. For example, when an agent is generated, a field corresponding to the role, that is, the type of the agent is designated. And the third
In the embodiment, by dividing the knowledge base for each field, it is possible to reduce the total amount of knowledge used in planning, and as a result, there is an effect of increasing planning efficiency.

[3-1-5-1. Action base] An action base is a set of action definitions that define actions that an agent can take together with its pre-conditions and post-conditions, and the set of actions includes a move command that implements the movement of an agent between nodes. As
Contains a go action. When the executor executes the go action as a command, the agent moves between nodes on the network, and executes the plan consistently before and after the movement.

[0184] In the action base, information on one action includes an action definition name, a precondition, and a postcondition in addition to the content of the action. First of all, the action definition name consists of the name of the action and its arguments (action parameters)
It is expressed by terms. In addition, the precondition is a condition for enabling the action to be executed, expressed by a list of terms. The post condition is a state change as a result of executing an action, also expressed by a list of terms.

Information on an action can be expressed, for example, in the following format. In the third embodiment, Pr
The olog predicate action is used to indicate that this description is an action definition. action (<action definition name>, <action>, <precondition>, <postcondition>). Here, <action> is composed of a command that can be executed by the executor. That is, it can be constituted by a plurality of command strings as shown below.

[3-1-5-2. Example of description format in action base] Here, Prol in the third embodiment
An example of an action-based description format using og will be described using a node action base as an example. The same applies to the description format of the agent action base and the field action base. / ***************************************************** ***** Action set action (action definition name, [commands composing the action], [preconditions], [postconditions]) ******************* *********************************** / action (goto, [goto (Node, maybe (exist (file (F), Node)))), [home (HomeNode), maybe (exist (file (F), Node))], [add (seeking_for (file (F), HomeNode, Node))]). goto, [update_agent_base (add (myself, returning, HomeNode)), goto_with_goal (HomeNode, return)], [have (file (F))], [add (bringing (file (F), HomeNode))]).

In the planning, an action necessary for achieving a goal is extracted from each action defined in the action base, and a script constituting the plan, that is, a sequence of actions is created.

[3-1-5-3. Information Base] The information base D2 in the third embodiment is also a generic name of the agent information base D2A, the field information base D2F, and the node information base D2N as in the case of the action base, and is a set of descriptions of facts regarding software resources on the network. It is. For example, the agent information base D2A is an information base that mainly stores information regarding the history of the behavior of the agent, such as what operation has been completed so far. The field information base D2F is an information base that expresses what processing is possible at the node for software resources unique to the field. The node information base D2N is a database that stores a description of what processing is possible and what resources the node has at that node. Of course, other information can be stored in each information base as needed.

Note that the agent information base D2A and the agent action base D1A are collectively referred to as an agent knowledge base DA. The field information base D2F and the field action base D1F are collectively referred to as a field knowledge base DF. Similarly,
Node information base D2N and node action base D
1N are collectively referred to as a node knowledge base DN.

[3-1-6. Planner] The planner performs planning based on a goal given for the purpose of information processing, and outputs a script as a plan that satisfies the goal, and constitutes a part of the function of the agent. Here, planning refers to generation of an action program by an agent. The plan is a sequence of actions generated by planning, and the script is a data structure or a file on software describing the plan. Scripts are described using script commands. That is, the script command is an execution instruction described in the script.

In the case of the third embodiment, the contents of planning are based on a set of pre-conditions and post-conditions (action definition) stored in a knowledge base uniquely possessed by nodes, fields, and agents. This will generate a sequence of actions to be reached. Note that the planner performs re-planning as necessary. The re-planning is a process of regenerating an agent action program when execution has failed.

The planning can be carried out by using the goal given by the user, the action base storing the action set, and the contents of the information base representing the current state expression. The planner is a module that receives these pieces of information as input and performs planning with script as output.

At the time of planning, the planner reads the agent knowledge base, the field knowledge base, and the node knowledge base for each of the action base and the information base, and performs planning after merging the contents thereof.

It should be noted that the planning process performed here may use a known process (reference: SCShapiro,
Pl in Encyclopedia of Artificial Intelligence
anning page). As an example of implementing the planner, a Prolog program in the case of using the Prolog language is shown below. / ******* Definition of planning *************** / plan (Goal, Node):-plan (Goal, Node, Node, _), halt.plan ( Goal, Node):-halt.plan (Goal, Home, Node, PL):-plan1 (Goal, Home, Node, PL), reverse (PL, PL2), tell (′ script ′), writePlanList (PL2), nl, told, write ('script = "'), write ('script'), write ('"'), nl.plan (Goal, Home, Node, PL):-tell ('script'), writePlanList ( [[′% No ′]]), nl, told, write (′ script = “′), write (′ script ′), write (′” ′), nl.plan1 (Goal, Home, Node, PL): -info (_, _),!, infoList (Home, Info0), goal (Goal, Home, Node, Info0, Info, [], PL, [Goal], _). plan1 (_, _, _, [ ['% No']]):-!, Write ('There are no info.'), Nl.goal (G, _, _, Info, Info, PL, PL, AGL, AGL):-member (G , Info). Goal (G, H, N1, Info0, [G | Info], PL0, [P1 | PL], AGL0, AGL):-action (_, P1, Pre, [add (G)]), goals (Pre, H, N2, Info0, Info, PL0, PL, AGL0, AGL). goals ([], _, _, Info, Info, PL, PL, AGL, AGL). goals ([G | GL] , H, N, Info0, Info, PL0, PL, AGL0, AGL):-goal (G, H, N, Info0, Info1, PL0, PL1, AGL0, AGL1),!, Goals (GL, H, N, Info1, Info, PL1, PL, AGL1, AGL ) .infoList (Node, L):-setof (Info, info (Node, Info), L) ./******* Output each action command included in the completed plan as a script file ** ************ / writePlanList ([]):-! .writePlanList ([A | L]):-!, writePlan (A), writePlanList (L) .writePlan ([]): -!. writePlan ([A | L]):-!, emitCommand (A), writePlan (L). emitFileList ([]). emitFileList ([F | FL]):-emitFileName (F), write (′ ′) emitFileName (file (FileName, Ext)):-!, write (FileName), write (′. ′), write (Ext) .emitFileName (DB):-!, write (DB). emitCommand (comment (G)):-emitCmd (comment (G)) .emitCommand (X):-emitCmd (X), nl.emitCmd (update_field_base (A)):-!, write (′% update_field_base ′), write EmitCmd (update_agent_base (A)):-!, Write (′% update_agent_base ′), write (′ ” EmitCmd (check (F, Node, R)):-!, Write (′% check ′), emitFileName (F), write (′ ′), write EmitCmd (check_with_goal (F, SG)):-!, Write (′% check ′), emitFileName (F), write (Node), write (′ “′), write (R), write (′” ′). EmitCmd (check_and_redo (F, SG, [G])):-!, Write (′% check_and_redo ′), emitFileName (F), write ( EmitCmd (goto_with_ack (N)):-!, Write ('% goto_with_ack'), write (')', write (SG), write ('""'), write (G), write ('"'). (N). EmitCmd (goto (N)):-!, Write (′% goto ′), write (N). EmitCmd (goto (N, at (P, NN))):-!, Write (′% goto ′), write (N), write (′ ”remove (′), write (NN), write (′, ′), write (P), write (′) ″ ′) .emitCmd (goto (N, Reason )):-!, write (′% goto ′), write (N), write (′ ″), write (Reason), write (′ ″ ′). emitCmd (goto_with_goal (N, G)):-! , write (′% goto_with_goal ′), write (N), write (′ ″), write (G), write (′ ″ ′). emitCmd (wait_and_goto (N)):-!, write ( emitCmd (put (F)):-!, write ('% put'), emitFileName (F) .emitCmd (get (F)):-!, write ('% get% wait_and_goto ′), write (N). EmitCmd (rename_file (F, G)):-!, Write (′ rename ′), emitFileName (F), write (′ ′), emitFileName (G) .emitCmd (plan_and_exe (G, C)):-!, Write ('% plan_and_exe "'), write (G), write ('""'), write (C), write ('"'). EmitCmd (fail (M)):- !, write ('% fail "'), write (M), write ('"'). emitCmd (comment (G)):-!. emitCmd (display):-!, write ('% display'). emitCmd (X):-!, write (X) ./****** prolog predicate definition ******* / setof (X, G, L):-setUp, G, setPush (X), fail. setof (X, G, L):-setPop (L). reconsult (F):-[F]. append ([], X, X). append ([A | X], Y, [A | Z]):-append (X, Y, Z). Reverse ([], []). Reverse ([A | X], Z):-reverse (X, Y), append (Y, [A], Z). Member (X, [X | _]). Member (X, [_ | L]):-member (X, L).

[3-1-7. Executor] The executor is a part that interprets and executes the script of the plan created by the planner. In other words, conceptually, the script generated by the agent using the planner is
The agent has an execution unit that interprets and executes a sequence of actions described in the script as a sequence of commands, and the agent operates by controlling both the planner and the execution unit.

The execution method and operation technique in the execution unit conform to a general interpreter language. The executor in the third embodiment essentially conforms to csh in the UNIX operating system, executes a script by executing a script, and returns an execution status as an output. The script commands interpreted and executed by the executor include the following.

[3-1-7-1. Examples of commands having functions common to csh] First, examples of commands having functions common to csh are as follows. For example, on a UNIX system, these commands can be processed by calling csh, but of course, they can also be implemented using another language processing system.

[Table 4]

[3-1-7-2. Control Structure and Variable Processing] In the script execution in the third embodiment, in principle, one command is executed in one line in order from the beginning to the end of the script, but using the following control syntax,
Conditional branching and repetitive processing can be performed. The details of the semantics of operations and how to write expressions are subsets of the C language specification.

[Table 5]

[3-1-7-3. Agent Command] The executor can use the following commands in the script to implement the processing required as a mobile agent. In the third embodiment, the types of commands can be extended by extending the executor.

[Table 6]

The meaning of “pick the subgoal into the goal stack” in the lowermost column of Table 6 is used in the current script, the execution position of the script, and the script in addition to the subgoal as shown in FIG. This means that the value of the variable is pushed onto the stack as a set of goal scripts. Of these, goto_with_subgoa
l command and check_with_subgoal command, and
plan_and_exe is a command with a subgoal. The command with a subgoal is a type of move command for moving an agent between nodes, and is a move command in which a subgoal to be executed as an alternative when a move fails is specified in advance.

On the other hand, the second goto instruction accompanied by “information of information base on which movement is based” from the top of Table 6 is a command with a basis. Generally, when an agent given a specific goal carries out planning, an action or command adopted in planning requires that the preconditions be satisfied in various knowledge bases. The precondition may be may information. However, there is no guarantee that may information is true in the actual network, so when the agent finishes planning and executes the completed script, the description content of the may information may differ. obtain. Evidenced commands are commands that have the function of correcting any errors in the maybe information found at the time of execution. In other words, a goto instruction accompanied by “information of the information base that is the basis of the movement” means that when the movement cannot be executed, it is determined that the preconditions at the time of planning are different, and as shown in Table 6, This command deletes the information in the information base given as an argument.

Similarly, the check command in Table 6 is a command with a basis. If the file specified in the first argument does not exist on the node where the agent executing the check exists, the check command considers the information specified in the third argument to be incorrect and returns the information specified in the second argument. Perform the operation of deleting from the base.

The action of these grounded commands is effective at the time of re-planning by the agent that has executed this command, or at the time of re-planning by another agent that follows as shown in an operation example later.

[3-1-7-4. Update predicate of information base] The update command in Table 6 serves as an interface to the updater 16 (FIG. 8), and updates the contents of the agent knowledge base, field knowledge base, and node knowledge base in the third embodiment. . There are two types of update predicates as shown in the following table.

[Table 7]

The update predicate is a directive for updating the contents of the information base based on the knowledge newly obtained by the behavior of the agent. Due to the presence of the update predicate, the agent updates information in the changing network, thereby re-planning the agent itself and planning for similar goals by other subsequent agents based on the new information. Can be implemented.

[3-1-7-5. Example of Simple Script] Here, a simple example of a script will be described using the above script commands. This script
File existing in the specified directory of node node1
This script moves file1 to node node0 and copies it. Assuming that the planner outputs this script, the agent executes this script in order from top to bottom. % goto node1% get file (file1)% goto node0% put file (file1)

[3-2. Operation] The third embodiment having the above configuration has the following operation. First, the activity of the agent in the third embodiment is started by giving a goal. In the following example, it is assumed that the following information is input to each database prior to the input of the goal. I do.

[3-2-1. Example of Action Definition] First, an action-based definition of a field used in this example will be described. The following example describes an agent that collects files distributed on a network and the fields for this collection. Five actions for achieving such a purpose are defined in the following fields. One action definition is a set of an action definition name, an action, a precondition, and a postcondition, as described above.

The action definition name is a name given for convenience. "Action" in the action definition is
Like the command of the executor, it represents the actual contents of the processing by the action. That is, the “action” in the action definition is a command included in a script generated by the planner when the action definition is adopted by planning, and is a command that is executed shortly after the agent enters the execution phase.

The precondition is a condition necessary for executing an action. This condition is used by the planner in the processing in planning and is not directly related to the execution phase of the agent.

The post condition is a condition added as a result of execution of an action. This condition is used by the planner in the processing in planning and is not directly related to the execution phase of the agent. That is, planning is a simulation prior to execution.

In the action base, for each field,
Action definitions according to the problem area must be made in advance. In this example, the action base includes five actions from the first action to the fifth action shown below.
Assume that one action is defined. In other words, the action base described below is based on node0,
It is distributed to each node of node1 and node2.
It should be noted that action-based distribution and correction to each node can be performed using the agent according to the third embodiment.

[3-2-1-1. Action: goto1]
In the first action definition, a move action for acquiring the file F in another node Node is defined. The contents of the first action definition are shown below. action (goto1, [update_agent_base (home (HomeNode)), goto (Node, maybe (exist (file (F), Node)))], [maybe (exist (file (F), Node)), home (HomeNode) ], [add (seeking_for (file (F), HomeNode, Node))]). As the contents of the first action definition, there are two specific commands. The command update_agent_base is an update operation for the agent information base. When this command is executed, the fact info (home (HomeNode)). Is added to the agent information base. This operation means that the node from which this agent has started is stored in the agent. The second action in this action definition is
It is a goto action with evidence. When this action is adopted in the planning, the agent that executes the generated script executes the grounded goto command that has been previously described as the executor command. The grounded goto action is a movement command, and the precondition of the command is attached as a parameter.

There are two preconditions for the first action definition. The first precondition is that a may predicate on the existence of a file at another node exists in one of the information bases, that is, one of three information bases: node, field, and agent. The second precondition is for binding the Prolog variable HomeNode and reflecting it in the argument of the postcondition, and is an item necessary for accurately reflecting the state of movement of the agent in the postcondition.

The post-condition of the first action definition indicates to the planner that the state of this agent is in the state of moving from HomeNode to Node in order to search for the file F across the network. The add in the post condition of this action definition is the update predicate given to the argument of each update command of the executor.
This is completely different from add (Table 7). In other words, add in this description is used by the action designer of the present system to instruct the planner on the state of the planning required for the planning, whereas the add
In the add of the te command, the script instructs the executor to add information to the information base. The meaning of the add predicate in the postcondition is the same for the following actions.

[3-2-1-2. Action: goto2]
The second action definition defines an action of copying the file F obtained by the agent to the original node HomeNode. The contents of the second action definition are shown below. action (goto2, [update_agent_base (add (myself, returning, HomeNode)), goto_with_goal (HomeNode, return)], [have (file (F))], [add (bringing (file (F), HomeNode))])) The action of the second action definition is the goto_with_goal movement command with subgoal. When this command is adopted in the planning, the goto_with_goal command of the execution unit described above is described in the generated script. The second action is goto_w
Prior to the ith_goal command, an update operation command update_agent_base of the agent information base is performed, which has a function of explicitly notifying the agent that the agent is in the return state. When this command is executed, the fact info (myself, returning). Is added to the agent's information base. This update_agent_base and goto_with_go
The two executor command operations of al are performed even if the agent temporarily returns to the HomeNode from the existing node due to a failure on the network.
The subgoal of turning gives the opportunity to replan.

The precondition of the second action definition is that the agent has already acquired the target file F, that is, have (file (F)). The second post-condition of the action definition, bringing (file (F), HomeNode), is that when this action is adopted, the state of the agent is in the state of acquiring the immediate target file F and returning to the HomeNode. Is shown to the planner.

[3-2-1-3. goto action] The third action definition is a command that, when the agent cannot be moved due to some kind of network failure, attempts to move it a predetermined number of times with a certain time interval as one measure. Is defined. The contents of the third action definition are shown below. action (wait_and_goto, [wait_and_goto (HomeNode)], [home (HomeNode), returning], [add (return)]). The action of the third action definition is to move a certain number of times at regular intervals. Wait_and_go to try. When this action is adopted in planning, the goto_with_goal command of the executor described above is described in the generated script.

The predicate returning shown in the precondition of the third action definition means that the agent has achieved the predetermined movement purpose and is in a state of returning to the original node, ie, HomeNodo. The predicate home (HomeNode) described before serves to bind the variable HomeNode.

[0220] The return indicated in the post-condition of the third action definition indicates to the planner that the state of the agent is in a state of returning to the HomeNode when this action is adopted.

[3-2-1-4. get action] The fourth action definition includes an instruction (for example, a put operation and a get operation) for acquiring an object (such as a file or data), and the agent carries the acquired object by moving the acquired object when moving. The agent returns to the generated node.

That is, this action relates to a state peculiar to the agent and relates to acquisition of a file by the agent. The contents of this action definition are shown below. action (get, [check (file (F), HomeNode, maybe (exist (file (F), Node))), get (file (F))], [seeking_for (file (F), HomeNode, Node), maybe (exist (file (F), Node))], [add (have (file (F)))]). In the action of the fourth action definition, two commands are described. When the check command is actually executed, it is checked whether or not the file F actually exists at the node where the agent exists. If the file F does not exist, the script execution of the agent fails. HomeNode, the first argument of the check command
Indicates the location of the knowledge base on which this check is based, and the second argument maybe (exist (file (F), Node))
Indicates the knowledge on which the evidence was based.

The predicate returning shown in the precondition of the fourth action definition means that the agent has achieved the predetermined movement purpose and is in a state of returning to the original node, ie, HomeNodo. The predicate home (HomeNode) described before serves to bind the variable HomeNode.

Have (file (F)) indicated in the post-condition of the fourth action definition indicates to the planner that when this action is adopted, the agent state is in a state of returning to the HomeNode. It is shown.

[3-2-1-5. put action] The fifth action definition relates to copying a file by an agent. The contents of the fifth action definition are shown below. action (put, [put (file (F)), update_field_base (add (HomeNode, exist (file (F), HomeNode)))], [bringing (file (F), HomeNode)], [add (exist (file (F), HomeNode))]). In the action of the fifth action definition, two commands are described. The put action copies the file F owned by the agent to the node where the agent is currently located. The update_field_base command is
Because the agent made a new copy of the file,
This indicates that information about the existence of the file is to be added to the field information base at the node where the agent is currently located.

The predicate bringing (file (F), HomeNode) shown in the precondition of the fifth action definition indicates that the agent is carrying file F to HomeNode. The add (exist (file (F), HomeNode)) shown in the post-condition of the fifth action definition is a post-condition that the agent has finished copying, and the planner is notified that the file F exists in the HomeNode. It is shown.

[3-2-2. Example of description of information base] Next, an example of description of an information base in the third embodiment will be described using an information base of a node as an example. info (node0, maybe (exist (file (file1), node1)))). info (node0, home (node0)). This information base is a description example of the information base in node node0. The first line description in this information base is
On node node0, file file1 is on node node1
Knowledge that exists in However, the nodes node0 and node1 are different hosts, and information on such other nodes is not always correct in a network where information is updated daily. The maybe information is information on such other nodes. The description on the second line is introduced in the third embodiment to express that the node node0 is exactly the node node0. The goal assumed in this example is the node node0
To get the file file1. File fi
le1 is a file created by a specific person using node1 or node2, and if file1 exists, the node where file1 exists is either node1 or node2 Can be assumed. This fact is described in the field make of the node node0 that plays the role of the accumulation area of the file file1.
Expressed as the following information base description contents. As described in the first embodiment, this information base can be automatically added to the information base by using an agent in another field belonging to the same network or another application software. is there.

In this example, for simplicity, it is assumed that the information base of the node and the action base of the node are empty. In this case, the field on node0
The field information base of make is as follows. info (node0, home (node0)). info (node0, exist (file (file2), node0)). info (node0, maybe (exist (file (file1), node1)))). info (node0, maybe (exist (file (file1), node2))). Here, the predicate info is a predicate explicitly expressing that it is an information base description in the third embodiment, and has two arguments. The predicate info in the third embodiment is a so-called Prolog fact expressed only by the head.
It is. The first argument of the head of the predicate info specifies which node the information is in. In the description example of the field information base, the content is all node0. The second argument of the head of the info predicate is information having a substantial meaning, and is expressed using a Prolog term. This description example has the following specific meaning.

[Table 8]

Information exist (file (file2), node0) and information mayb
The difference of e (exist (file (file1), node1))) is that in the former, it is information about the file that exists in node0 to which the information base of this description belongs, and it can be described in the information base as a fact. Whereas the latter predicate is the other node no from the viewpoint of node0.
This is a description of the facts about de1 and reflects the fact that the validity of the description cannot always be guaranteed at node0 in a network that assumes changes.

Therefore, the meanings of the four info predicates in the field information base are as follows. -The node to which this field belongs is node0. -File file2 exists in node0.・ Assume that file file1 exists in node1.・ It is also assumed that file file2 exists on node2.

Next, it is assumed that the following contents are stored in the field information base of node1. This is fi
With respect to le1, based on the previously obtained knowledge that its existence exists at node1 or node2,
Is a predicate of info (node0, maybe (exist (file (file1), node2))). Similarly, the following information may be stored in the field information base of node2. info (node0, maybe (exist (file (file1), node1)))). The maybe information described here is also a type of the info predicate shown above. Each information base, that is, a part of an info predicate included in the agent information base, the field information base, and the node information base is configured. The above information is given to the planner when the agent moves to the planning phase. These info predicates are preconditions that the planner needs to select an action.

[3-2-3. Input of Goal and Generation of Agent] In the information processing apparatus of the third embodiment having the above information, when a goal is given to a node, the node manager 15
Is generated, and the planner 13 generates a plan. In the third embodiment, the planner 13 is activated by giving a goal. In the implementation of the planner using Prolog in the third embodiment, a script having an agent name as a file name is generated by giving a goal description as a Prolog query (question). Third
The goal in the embodiment can be described as (example) exist (file (file1), node0) when the contents of each base described above are assumed. This goal is the file
This means acquiring file1. In other words, it means that file file1, which does not currently exist on node node0, is copied from one of the other nodes and is made to exist on node0.

As a specific example of inputting the goal to the planner, the following query is issued to the planner. This goal is effective when combined with the action base and the information base described above.

(Example): -plan (exist (file (file1), node0), _). The agent generation is executed by giving this goal description to the node manager 15 of the field make of node0. This operation is performed through predetermined input / output means.

FIG. 16 shows an operation procedure of the node manager including generation of an agent. The node manager has a list (active agent list) AL for registering agents (active agents) existing in the node (FIG. 14). And
As shown in FIG. 16, the node manager 15 receives communication contents from the node / port NP (FIG. 14) as an instruction from another node manager or an agent process (steps 1501 to 1505), and receives a character string given as the instruction. According to the contents of the string (step 1506
To 1510), generation of an agent (step 151)
1, 1512), disappeared (steps 1521, 1522)
Alternatively, processing such as movement (steps 1531 to 1553) is performed to update the active agent list.

The node manager determines the processing contents of each interface by interpreting the contents of the words sent as described above. There are various methods for transferring the words. Therefore, a desired method may be freely adopted.

The agent process 17 (FIG. 8) generated by the agent manager 15 realizes the operation of the agent A as a whole while being generated / managed by the node manager 15. Note that the node manager 15 can simultaneously generate a plurality of agent processes 17.

After the generation of the agent, the agent name is given to the agent by the node manager 15. As agents move between nodes in the network, the agent name must be the only name in the network to identify the agent. The node manager 15 combines the information such as the node name, the time, and the number of agents generated so far, and gives the generated agent a unique agent name in the network. The generated agent has three phases of planning, execution, and movement as described below, and enters each phase as necessary.

[3-2-4. Creation of Plan] When a goal is given and an agent is generated, the planner 13
Performs planning for the given goal. That is, first, an agent is generated by giving a goal exist (node0, file (file1)). From a predetermined input / output device, and the agent enters a planning phase. That is, the agent executes the planning by loading the goal script set on the goal stack and activating the planner 13.

FIG. 17 is a conceptual diagram showing the contents of plan creation in the form of a flowchart, and is a diagram for explaining a known planning technique. That is, the planner 13 in the third embodiment performs backward inference from the goal, and obtains an action sequence satisfying the goal while referring to the precondition and the postcondition. In other words, FIG. 17 simply describes the actual planning operation, and simplifies the operation by omitting operations such as unification of variables and atoms that occur in the actual Prolog operation. It is described.

In this planning, as in the first embodiment, an action definition having a goal as a post condition is searched. Next, each precondition in the found action definition is set as a goal, and an action definition having the goal as a postcondition is searched. Then, the plan is created by writing the script to the plan, and using the written action as a goal, and repeating the same procedure. That is, specifically, from the goal (step 160)
1) tracing actions put, goto2, get, goto1 until all conditions are satisfied (steps 1602 to 160)
5) Repeat the procedure. Since this search is performed in the reverse direction from the goal to the current state, the selected action definitions are reversed in the order selected, and the contents of the actions in those action definitions, that is, the command sequence Is generated as a script. At this time, if all the conditions cannot be satisfied regardless of the order of the action definitions, planning fails.

By the processing in FIG. 16, the following plan result is obtained as a script based on the field knowledge base of the field make of node0 and the action base of node0. The leftmost number is a line number. 1% update_agent_base "add (myself, home (node0))" 2% goto node1 "maybe (exist (file (file1), node1))" 3% check file (file1) node0 "maybe (exist (file (file
1), node1)) "4% get file (file1) 5% update_agent_base" add (myself, returning, node
0) "6% goto_with_goal node0" return "7% put file (file1) 8% update_field_base" add (node0, exist (file (file
1), node0)) "

Note that the planner 13 executes the command go in Table 6.
As shown in to (second), when creating a move command for moving an agent between nodes as part of a plan, a precondition as a premise of the command is attached. That is, it means that the reason for moving to node1 is "maybe (exist (file (file1), node1))". When the precondition is attached to the movement command, all or a part of the precondition is set as an attached parameter of the movement command.

As described above, in the third embodiment, a precondition is attached (as a basis) to a movement command. When the movement based on the movement command fails, it is most likely that the preconditions premised on the command have not been satisfied. This precondition is attached to the instruction and can be easily found by referring to the instruction. For this reason, it is easy to respond to the movement failure.

The planner 13 reads the action base and the information base of the node, the action base and the information base of the field, and the action base and the information base of the agent before executing the planning. In the third embodiment, the above is generically called a knowledge base. In the implementation using Prolog in the third embodiment, as described above, the information of each information base is Pr
Because it is expressed by the olog section, planning can be performed by reading all the above knowledge bases using Prolog assertions before planning.

According to the above query, the file name 'scr
A script called ipt ′ is generated once. The agent process then renames the file according to the corresponding unique agent name to distinguish it from other concurrent agent scripts. of course,
If multiple agents are planning at the same time, they are a parallel process, so it is necessary to synchronize the operations of the agents when creating and deleting files, but by introducing an appropriate locking mechanism, Agents can be on the same node.

Depending on the contents of the goal, the knowledge base of the nodes, the knowledge base of the field, and the contents of the knowledge base of the movement, the planning may succeed or fail. If successful, a script that is the output of planning is generated and the agent moves to the execution phase. In addition to the goal given at the time of generation, the agent
It has a goal stack that can store a plurality of subgoals for recovering from a failure in the middle. Then, when the planning of the subgoal fails, the planning is performed by the higher goal. A state in which all planning finally fails is a complete failure. In the case of a complete failure, the agent is terminated.

Since the above script is obtained as a result of the planning, the agent stores the script in the goal script set at the top of the goal stack. Next, the agent moves to the execution phase.

In the planning, an intermediate goal for achieving the goal, which is the final goal, may be created, and a child agent for achieving the intermediate goal may be generated. In this way, since the creation of intermediate goals is entrusted to the child agent, the content of information processing for each agent is simplified,
Information processing is made more efficient. In addition, information processing is speeded up by a plurality of agents operating in parallel or in parallel.

[3-2-5. [Execution of Plan] When the script description is generated, the agent makes a decision regarding a constraint and makes necessary plan corrections, and then enters an execution phase using the execution unit 16. As described later, the script is a sequence of commands having a control structure. The agent in the execution phase interprets the script according to the control structure and executes the commands in order.

FIG. 18 is a flowchart showing a procedure for executing a plan. In this procedure, commands are read out line by line while increasing the execution line number until the script ends (steps 1701 to 1704, 1715,
1716) If it is a move command, the agent manager is requested to do so, and other than the move command, processing corresponding to the type of command is performed (step 1708). If an error occurs during the execution (step 1709), predetermined error processing is performed for each type of command in which the error has occurred (steps 1710 to 1714).

That is, the executor 16 reads the script, cuts out the command line by line, interprets the command name and the script, and executes the command shown in the above table according to the type of the command. There may be various variations in the grammar of the script executed by the executor. Regarding the grammar interpreter to be used, regardless of the essence of the present invention,
It is characterized in that a moving command as shown in the table, a command for updating the information base shown in the table, and a command for specifying the information serving as the basis are prepared in the execution unit. By providing these commands, it becomes possible to give an appropriate subgoal to the agent or to appropriately update the information base in response to a change in the network.

If the execution of the command fails or the re-plan command is executed, the process returns to the planning phase for performing planning based on a predetermined goal. If the move command has been executed, the process moves to the move phase.

[3-2-6. Move Agent] When the executor 16 encounters a move command in a script being executed, it is notified to the node manager 15 and the agent is transferred to another node. The information actually transferred to move the agent is a script,
Agent, goal stack, agent knowledge base. If all of this information has been successfully transferred to the destination node, the agent returns to the execution phase at the destination.

[3-2-6-1. Movement of Agent to Another Node] FIG. 19 is a flowchart showing the operation of the node manager of the source node when the agent moves to another node. That is, while collecting necessary information about the agent (step 1)
802 to 1804), communication is attempted using the destination node as a host (steps 1805 and 1808). If the establishment of a communication path fails, the movement is abandoned (step 180).
6, 1809), and notifies the agent process of failure (steps 1807, 1810). When the communication path is established, necessary information is transmitted to the destination, and a response is waited for (steps 1811, 1812, 1815). Even if the communication path is established, a reply from the destination node can be received. If the transfer is not successful, the transfer is similarly regarded as a failure (step 1813), and the agent process is notified (step 1814).

[3-2-6-2. Movement of Agent from Another Node] In correspondence with the process of FIG. 19, the node manager of the destination node accepts the agent by the process shown in FIG. That is, the node manager sends the protocol M from another node to the node port.
When receiving the F, necessary information is received (step 1901), resources are allocated to a new agent (step 1902), information of the new agent is stored in a predetermined storage area (step 1903), and the source Reply to the acceptance success (steps 1904, 190
5) Start the agent process (step 19)
06) If a communication error occurs during this process, it is handled by an exception handling mechanism used in Java or C ++ object-oriented languages.

FIG. 21 is a supplementary explanatory diagram showing how an agent moves using an agent = node interface and a node = node interface. The agent moves indirectly via the node manager.

[3-2-7. Responding to Failure] If the execution or movement of the script fails, that is, if the execution of the plan fails, the execution of the plan is interrupted, and the plan is created and executed again. As a mode in which the failure occurs,
For example, an error or an exception may occur. In the third embodiment, even if the execution or movement of the plan fails, the plan is created again, so that the information processing is smoothly continued.

Specifically, when the execution or movement of the action in the plan fails, a subgoal for recovering the failure of the execution or movement is generated, and the execution of the plan is resumed after the execution of the subgoal is completed. Save the information of, create a plan and execute the plan based on the subgoal, after the execution of the plan based on the subgoal,
The execution of the original plan is continued using the stored information.

For example, if the movement of the agent based on the go command has failed and no basis has been added to the go command, planning is performed again using the goal for which the current script has been generated as the goal again.
If the migration fails, the network connection to the destination node has not been established, or the migration has not been completed within a certain period of time, or the required resources such as memory and disk space are not secured at the destination. Can be considered. In such a case, it is considered that the movement command has failed, and the process returns to the planning phase based on the predetermined subgoal.

Such a failure is desirably detected on the source side. For example, when the agent executes the go command, in the node manager that manages the movement of the agent, if the agent cannot move due to some trouble in the destination node, the failure of the agent movement is detected at the source.

As described above, creating a plan by creating a subgoal in the event of a failure means shifting to the planning phase as needed even during the execution phase. The information to be stored may be the original goal, the original script, the execution position of the script, and the like. In order to save such information, the information may be stored on the goal stack. Then, planning is performed from the lowest subgoal among the created subgoals, and the created plan is executed. To resume the original plan after execution, the saved information may be taken out of the stack and used.

Also, in the third embodiment, the planning,
If the execution of the plan or the movement based on the plan fails, the information that caused the failure is corrected. For this reason,
Subsequent failures are reduced, and processing is made more efficient. For example, when the execution of the go command in which the precondition is specified as a parameter fails, the executor 16 deletes the precondition from the local information, that is, the field information base.

The mode for creating a subgoal and correcting information is based on a method defined in advance for each action or destination, or a method defined by any information used in the plan creation. In addition, it may be determined based on local information or the like.

As described above, in the third embodiment including the case of coping with a failure, a hierarchical goal is created by creating a subgoal in the execution of a plan, and further creating and executing a plan for the subgoal. Information is processed using the structure of. In this case, the agent moves with a hierarchical goal stack when moving with the go action, so that the destination node can perform consistent operation using the same goal stack as before moving. it can.

In order to smoothly perform such replanning, a replan command is used as one type of action constituting a plan. When the replan command is executed during the execution of the plan, the plan creating means changes the subplan. create.

If the planning fails after the move and an action that satisfies the precondition cannot be finally generated, the script execution is ended with failure, returns to the node before the move, and saves in the stack. It is sufficient to re-plan using the goals already set. Further, in the event that the generation of a plan for a goal is finally impossible or an unexecutable goal is received, the sender may be notified as necessary by e-mail or other means. .

As another mode of error countermeasures, the means for creating a plan includes a script for confirming whether or not a precondition as a premise of the plan is satisfied at the time of execution of the plan. Can be added to Thereby, it is confirmed at the time of execution that the conditions at the time of the plan creation are satisfied. That is, since a time interval necessarily exists between the time when the planning is performed and the time when the created plan is executed, the condition satisfied at the time of the planning is
At runtime, there is a possibility that it is not already satisfied.
Confirmation of the preconditions ensures proper execution of the plan.

[3-2-8. End processing] As an example of the end processing, when the agent succeeds in the information processing,
A process of transmitting a success mail to the goal issuer and sending a failure mail in the case of failure is conceivable. In addition, various realization modes can be considered as the termination processing. By adding information on which termination processing is to be performed when the agent is generated, a variation of the termination processing is provided. Is also good.

[3-2-9. Detailed Operation of Agent] FIG. 22 is a flowchart showing a processing procedure in which each of the above operations is mainly described for the agent. That is, when a goal is received from the node manager when an agent is generated, the goal is stacked on a goal stack (step 2101). It is checked whether or not the goal stack is empty (step 2102). If the goal stack is empty, it is determined that this agent has completely failed to achieve the goal, an end process described later is performed, and the process ends (step 2103). ).

If the goal stack is not empty, a goal is popped from the goal stack, and planning for the goal is performed (step 2104).
If the planning fails, the process returns to the step of checking the contents of the stack (step 2105).

If the planning is successful, a script is generated (step 2106). At this time, the execution position of the script is updated (step 2107), and the process moves from the planning phase to the execution phase.

For planning and script generation,
Planning immediately after a new agent is created,
In, a new script is generated. In the planning and the generation of the script, in the planning immediately after the newly created script, the result of the planning is added to the script existing before the planning. If the planning and generation of the script were not successful,
Return to the step of checking if the goal stack is empty.

If the plan generation succeeds, the operation shifts to script interpretation and execution. The interpretation and execution of the script are processed by an agent execution unit described later. The operation of interpreting and executing a script is essentially the same as that of a general interpreted language such as BASIC. The executor reads the command by moving the current execution position of the script to the next position, interprets the command type and the command argument, and executes the command.

If the interpreter of the executor determines that the command at the current execution position is a move command (goto), the process moves to a move processing step (step 2108). In the movement processing step, movement processing described later is performed. The transfer process is a process performed by the node manager to span between nodes. The agent disappears from the source and is restored to the destination (step 2109). When this movement is completed (step 2110), the processing of the flowchart in FIG. 22 is continued at the destination node.

If the movement has failed (step 211)
0) At the source node, check whether the move command is a move command with a goal (step 2).
114). In the case of a movement command without a goal, the process returns to the step of checking whether or not the goal stack is empty to enter the planning phase next. In the case of a move command with a goal, a failure process described later is executed (step 2115), the subgoal is pushed on the goal stack (step 2116), and the process returns to the planning step again.

If the command at the execution position is not a move command (step 2108), then the executor checks whether the script has ended (step 2111). If the script has been completed, it is determined that the agent has been successfully completed.
7), end.

If the script is not completed in step 2111, the command at the execution position is interpreted and executed (step 2112). In this process, if the command execution is successful, the process returns to the step. Also,
If the command execution has failed, the process moves to step 2114 (step 2113).

The above is the behavior from the viewpoint of the moving agent. The agent generates a script to meet the initially given goal as a whole,
Show consistent behavior based on script.

[3-3. Example of Script Execution and Node Movement] Subsequently, regarding the behavior of the agent in the execution phase and the movement phase of executing the script generated by the planner, the above-described script (hereinafter, referred to as “first script”) is a specific example. It will be described as. FIG. 23 is a flowchart illustrating a process including a response to a failure in the specific example.

[3-3-1. Successful example] First, a specific example of a successful example in which all assumptions in planning are correct and no error occurs during execution will be described.

First, in the plan described above, the information, info (myself, home (node0)) is stored in the information base of the agent by executing% update_agent_base “add (myself, home (node0))” on the first line. Is added (step 2201). The operation will fail for some reason after this script execution,
When performing re-planning, it is necessary to inform the planner of its own departure node.

Next, the execution of% goto node1 "maybe (exist (file (file1), node1))" on the second line is a move instruction with a basis to node1, and the agent moves to node 1 by this instruction. (Step 2201). The effect of the argument basis will be described later.

Subsequently, the third line,% check file (file1) node0 "maybe (exist (file (file1),
By executing “node1))”, it is confirmed whether or not file1 actually exists in the node node1 (step 2205). In this example, as assumed in the planning, file1 is changed to node1.
Shall exist. In this case, the second and third arguments of the check command have no meaning.

Thus, by executing% get file (file1) on the fourth line, file1 is moved from node1 to node1 as the file owned by the agent (step 220).
9). Thereafter, the agent moves and carries file1 until the agent puts the file.

By executing% update_agent_base "add (myself, returning, node0)" on the fifth line, information info (myself, returning, node0) is added to the information base of the agent (step 2209). This operation is performed in order to reflect the fact that the agent is in the return state in the planning when the subsequent return of the agent to node0 fails for some reason and the replanning is performed.

Then, by executing% goto_with_goal node0 "return" on the sixth line, the agent moves to node0 (step 2209). By executing% put file (file1) on the seventh line, file1 owned by the agent is changed to node0.
(Step 2214). Finally, on line 8,% update_field_base "add (node0, exist (file (file1),
By executing “node0))”, the agent adds info (exist (file (file1), node0)) to the field information base of node0 (step 2214). As described above, the agent executes the script. As long as there is no execution failure on the way, it works to satisfy the goal given first.

[3-3-2. Failure Example] Next, the operation of the agent at the time of executing the replanning will be described based on a failure example. The planning done on node0 is
At 0, we have just planned using as much information as we know. Actually, the state of each node connected to the network and the state of the network change with the passage of time, so that execution of the script generated by the planning may fail in the middle.

The failure of the execution of the agent may be for the following reasons. (1) The node or network does not operate temporarily due to failure, maintenance, or overload. (2) The information base used by the agent for planning is incorrect. (3) The content of the information base has become outdated over time.

As shown in FIG. 17, in the present operation example, the following case can be considered. -Moving the agent from node0 to node1 fails. -File does not exist on node node1, and the agent cannot acquire the file (it exists on node2 instead). -Moving the agent from node1 to node0 of file file1 fails.

In the following, how the information processing apparatus according to one embodiment of the present invention handles the above cases will be described.

[3-3-2-1. First failure example] First, the second line of the script% goto node1 "maybe (exist (fil
e (file1), node1)) "(Step 2201), the case where the transfer of the grounded goto instruction from node0 to node1 fails (failure scenario 1 in FIG. 23). In this case (step 2202), the node The manager performs the operation shown in Fig. 19, and notifies the agent that it cannot move.
In response to this, at the time of planning, the information serving as the basis of the movement, that is, the knowledge of the third argument is deleted from the information bases of the node, the field, and the agent (step 2203). The information base changes as follows by the removal of the basis.

First, the node information base of node0 is the third
In the case of the embodiment, there is no change since there is no content from the beginning. In the case of the agent information base, update_agent_b in the first line of the first script preceding it
By executing the ase command, info (myself, home (node
0)). (English clause)
Since the clause of the maybe predicate does not exist in the agent information base, nothing is changed.

On the other hand, node no at the time of the first failure
The contents of the information base of the field make of de0 is info (node0, home (node0)). info (node0, exist (file (file2), node0)). info (node0, maybe (exist (file (file1), node2 After this work, the executor returns a status of execution failure to the agent process, and the agent shifts to the planning phase. Since the failed goto instruction is a command having no subgoal, FIG.
Based on the above operation, replanning is performed with the contents of the current goal stack (step 2204).

The following second script is generated by the above field information base, agent information base, the above-mentioned action base, and the re-planning by the above-mentioned planner.

% Update_agent_base "add (myself, home (node0))"% goto node2 "maybe (exist (file (file1), node2))"% check file (file1) node0 "maybe (exist (file (file1),
node2)) "% get file (file1)% update_agent_base" add (myself, returning, node0) "% goto_with_goal node0" return "% put file (file1)% update_field_base" add (node0, exist (file (file1),
node0)) "The difference between this script and the first script is the file
The point that 1 is obtained is changed from node1 to node2.

That is, if the information base is not properly updated due to execution failure, the same script as the first script is generated even if replanning is performed.
Agents may repeat the same mistake. In the third embodiment, by using the grounded go command,
The information info (node0, maybe (exist (file (file1), node1)))., Which indicates that file1 exists in node1, was deleted from the contents of the field information base. Therefore, at the time of re-planning, a plan was created using nodo2, which is the next candidate where file1 could exist. As described above, according to the third embodiment, it is possible to improve the autonomy of the agent required for the software agent and increase the agent's ability to respond to changes on the network.

[3-3-2-2. Second failure example]
In the first script, the behavior of the agent in this operation example in the case where the movement from node0 to node1 succeeds but file1 does not exist in node1 will be described (failure scenario 3 in FIG. 23). In this case, node1
When the agent executor that has moved to step 1 checks the existence of file1 in the check command on the third line of the first script, execution failure occurs because file1 does not actually exist (step 2205).

As shown in the table of the executor commands, the second argument of the check command is the basis and source, that is, the node where the information base in which the information as the basis is stored exists, and the third argument is Is the base information.
As in the first failure example, in this case, the information serving as the basis is updated (step 2207).

However, the difference between the case of the first failure example and the case of the second failure example is essentially that the agent has already
It is moving to node1. Therefore, in order to update the contents of the information base, it is necessary to move to the original node again. Here, a method is used in which the node in which the incorrect information base exists is specified in the check command, and the field information base and the node information base (both) of the node are updated.

At this time, as means for updating the contents of the information base, the information base is updated using inter-node communication via the node manager, or a goal for updating the information is separately issued, There is also a method of generating an agent separately and operating it independently. In either case, the presence of the evidenced command allows the information base to be updated.

In the replanning at node1, the information bases used are the node information base of node node1,
The information base of the field of node node1 and the information base of the agent.

In the second failure example, the content of the agent information base in the update after the failure is info (myself, home (node0)). On the other hand, the content of the node information base of node1 is empty. The content of the field information base of the field make of node1 is info (node1, maybe (exist (file (file1), node2))). From these two pieces of information, similar to the failure example 1, when the re-planning for the original goal exist (file (file1), node0) is performed (step 2208), the following script similar to the first failure example is obtained. . The difference is that in the first failure example, the agent moves from node0 to node2, whereas in the second failure example, the agent plans to move from node1 to node2. % update_agent_base "add (myself, home (node0))"% goto node2 "maybe (exist (file (file1), node2))""% check file (file1) node0" maybe (exist (file (file1),
node2)) "% get file (file1)% update_agent_base" add (myself, returning, node0) "% goto_with_goal node0" return "% put file (file1)% update_field_base" add (node0, exist (file (file1),
node0)) "This is because the presence of the agent information base makes it possible to use the home node position of the agent when it is moved to another node.
This has the effect of maintaining the consistency of the agent during movement.

[3-3-2-3. Third failure example]
As a third failure example, in the first script, node
Although it succeeded up to get of file1 in 1 (step 220
9) The behavior of the agent in the present operation example when the movement of the agent fails at the time of the last movement to return to node0 will be described.

The failure occurs on node 6, at% goto_with_goal node0 "return" on the sixth line of the first script. This is a move instruction with a subgoal, where the third argument "return" is the subgoal. Therefore, in the present example, even if the same movement failure occurs, the method of handling the movement failure by the agent must necessarily be different from the case of the first failure example.

The execution unit of the agent executes the no-goal command “goto_with_goal” according to the procedure shown in FIG.
Receives notification from the node manager that migration from de1 to node0 failed, and fails execution. In this case, the sub-goal "return" is inserted into the stack of the script being executed at that time along with information such as the current execution position, and the like.
A re-plan is performed (step 2211).

The contents of the agent information base at the time of re-planning are as follows because there is content addition in the fifth line of the first script prior to execution of the goto_with_goal command. The added knowledge retruning has the effect of explicitly stating that the agent is in a state of returning to the home node, node0.

% Info (myself, home (node0)).% Info (myself, returning). On the other hand, as in the case of failure example 2, the field ma of node1
The content of the ke information base is the following line.

% Info (node1, maybe (exist (file (file1), node2))). The content of the node information base of the node node1 is empty.

[0310] The fourth script generated by the information base, the action definition and the planner described above is the following one line. % wait_and_goto node0 This command is a command that attempts to move a predetermined number of times at regular intervals (step 2212). It is assumed that the previous move to node0 failed unfortunately due to a temporary failure of the network. In this example, the initial agent goal exist (file (file1), node2)) is no
It implicitly requires the existence of de0, and it is not necessary to consider the possibility that node0 may have disappeared due to a change in the network. Therefore, it is reasonable to assume that the failure to move from node1 to node0 is a temporary failure.

Wait which is a script resulting from replanning
If it is not possible to move to node0 even after executing _and_goto node0 (step 2213), since there are no more subgoals, the agent pops the goal stack according to the procedure of FIG. 22 and executes the first goal exec (file (file1)). , n
Re-plan again using ode1). The script generated in this case is the same as in the second failure case,
Move to node2 and then back to node0. Furthermore, this node
If the execution of the plan to move to 2 also fails, the agent fails completely. A predetermined termination process is performed, and the fact that the agent has completely failed is recorded in any of the nodes.

Wait, which is a script resulting from replanning
If the execution of _and_goto node0 leads to node0, this fourth script will exit successfully,
The agent pops the goal stack according to the procedure shown in FIG. 22, and resumes execution from the seventh line of the first script at node0. Such subgoal execution has the effect of searching for an alternative using the knowledge of the destination node to find a problem with respect to the local purpose that occurred when the agent returns to node0 in this embodiment.

Also, the existence of the goal stack in the agent and the transportation during its movement have the effect of giving a chance to redo the planning with a larger goal if such a local alternative does not succeed.

The first action and the second action in the action definition are both movement commands,
Whereas the first action is a move to search for the file F, the second action is an action definition for the agent to execute a predetermined command at the destination and return to the source. Was able to define the difference.

As described above, in the third embodiment, as described in the first and third failure examples, even in the case of the same movement command, an action description for issuing a subgoal according to the context of the agent is possible. As a result, it becomes possible to describe an autonomous agent that can cope with many unexpected changes.

[3-4. Effect of Third Embodiment] As described above, in the third embodiment, the agent moves to the field corresponding to the purpose of the information processing and the type of the agent, and only the information of the field is used in the plan creation. The amount of search processing required is reduced, and plan creation is made more efficient. In particular, in the third embodiment, since the third information and the fourth information relating to the modification of the constraint and the plan can be set for each field, security safety suitable for each field is ensured.

In the third embodiment, each agent carries unique fourth information even when moving between nodes, and the destination node also uses the fourth information to modify the plan. It is possible to apply an optimal plan modification method according to the purpose and state of each agent.

[0318] In the third embodiment, a precondition is attached to a move command as a basis. If the movement based on the movement command fails, the preconditions premised on the command may not have been satisfied. Since this precondition is attached to the movement command, it can be easily understood by referring to the movement command. For this reason, the cause of the movement failure is specified, and handling of the failure becomes easy.

[4. Other Embodiments] The present invention is not limited to the above embodiments, but includes other embodiments as exemplified below. For example, the third
And the contents and format of the fourth information are arbitrary, and a specific method of responding to the failure of the generation or modification of the plan is merely an example and can be freely determined. Also,
In the embodiment of the present invention, it is not always necessary to use a configuration in which a knowledge base is divided into fields, information unique to an agent is used, or a precondition is attached to a movement command. Further, in the implementation of the present invention, it is not always necessary to use a configuration in which a child agent is generated, replanning is performed when execution fails, and information that causes a failure is corrected.

[0320]

As described above, according to the present invention,
Since harmful behavior such as the agent overloading the host can be prevented, it is easy to ensure stable operation of the system.

[Brief description of the drawings]

FIG. 1 is a functional block diagram showing a configuration of an information processing apparatus according to a first embodiment of the present invention.

FIG. 2 is a flowchart showing a processing procedure of information processing according to the first embodiment of the present invention.

FIG. 3 is a flowchart showing a procedure for generating a plan according to the first embodiment of the present invention.

FIG. 4 is a tree diagram showing contents of a plan generated in the first embodiment of the present invention.

FIG. 5 is a flowchart illustrating a procedure of agent transfer according to the first embodiment of the present invention.

FIG. 6 is a view showing a display example according to the first embodiment of the present invention.

FIG. 7 is a diagram illustrating importance and relevance of each document according to the second embodiment of the present invention.

FIG. 8 is a functional block diagram showing a configuration of a node according to a third embodiment of the present invention.

FIG. 9 is a block diagram showing a configuration of a node included in an information processing device according to a third embodiment of the present invention.

FIG. 10 is a conceptual diagram showing a state in which a node is divided into fields according to the third embodiment of the present invention.

FIG. 11 is a diagram showing a plurality of phases constituting an operation of an agent in the third embodiment of the present invention.

FIG. 12 is a diagram showing a logical structure of an agent according to the third embodiment of the present invention.

FIG. 13 is a diagram showing a data structure of a goal script set in the third embodiment of the present invention.

FIG. 14 is a functional block diagram showing a mode for realizing communication relating to a node manager in the third embodiment of the present invention.

FIG. 15 is a diagram showing a structure of a knowledge base in the third embodiment of the present invention.

FIG. 16 is a flowchart showing an operation procedure of a node manager in the third embodiment of the present invention.

FIG. 17 is a view showing contents of planning in a flowchart form in the third embodiment of the present invention.

FIG. 18 is a flowchart showing a procedure for executing a plan in the third embodiment of the present invention.

FIG. 19 is a flowchart showing an operation procedure of a source node manager when an agent is moved between nodes in the third embodiment of the present invention.

FIG. 20 is a flowchart showing an operation procedure of a destination node manager when an agent is moved between nodes in the third embodiment of the present invention.

FIG. 21 is a diagram showing a state of an agent moving between nodes via a node manager in the third embodiment of the present invention.

FIG. 22 is a flowchart showing an operation procedure of an agent in the third embodiment of the present invention.

FIG. 23 is a flowchart showing the contents of handling plan execution in the third embodiment of the present invention.

FIG. 24 is a functional block diagram showing a configuration of an example of a conventional information processing apparatus.

FIG. 25 is a diagram showing a security / safety measure in the related art.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 ... Local information storage means 2 ... Update means 3 ... Agent information storage means 4 ... Input / output means 5 ... Plan generation means 6 ... Plan execution means 7 ... Agent management unit 8 ... Third storage unit 9 ... Judgment unit 10 ... 4 storage unit 11 ... correction unit L ... local machine R ... remote machine N ... network STEP ... each step of the procedure 11, 12, 20, D ... knowledge base 13 ... planner 14 ... execution unit 15 ... node manager 16 ... update Device 17: Agent process 18: GUI application 19: Node management information storage means 101: Memory 102: CPU 103: Auxiliary storage device X: Host FL: Field A: Agent STEP ~, after 1501 ... Steps in the procedure

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Akihiko Osuga 70, Yanagicho, Kochi-ku, Kawasaki-shi, Kanagawa Prefecture Inside the Toshiba Yanagicho Plant (72) Inventor Shinichi Honda 70, Yanagicho, Kochi-ku, Kawasaki-shi, Kanagawa Toshiba Yanagicho Co., Ltd. F-term in the factory (reference) 5B045 GG01 5B089 GA01 GB03 GB08 JA11 JB07 KA06 KC39 KC51

Claims (12)

[Claims] 1. An information processing apparatus for performing information processing by an agent, which is an execution entity on software, operating on a node connected to a network, wherein the agent is used for accessing a component arranged at the node. A first storage unit for storing first information representing a state of a component, a second storage unit for storing second information defining behavior of the execution subject, and the first storage unit. Means for creating a plan to be executed by an agent based on the second information to achieve a given purpose, and third information representing constraints that the plan must satisfy for node security A third storage unit for storing the constraint, a unit for determining whether the plan satisfies the constraint, and a plan for the plan determined to satisfy the constraint. Means for realizing execution and movement of an agent between nodes, wherein an information processing apparatus is configured to create and determine a plan even at a destination node. 2. A fourth storage means for storing fourth information indicating how to generate a plan that satisfies the constraint, and when it is determined that the plan does not satisfy the constraint, The information processing apparatus according to claim 1, further comprising: means for correcting a plan based on the fourth information. 3. The apparatus according to claim 2, wherein at least one of the nodes includes a plurality of fields that are active areas of an agent, and at least one of the first to fourth information is stored for each field. 2. The information processing apparatus according to item 2. 4. The information processing apparatus according to claim 2, wherein the agent carries the unique fourth information also when moving between nodes. 5. A method for creating a plan, comprising: creating a move instruction or another instruction for moving an agent between nodes as a part of a plan, by setting a precondition premised on the instruction to the move instruction or The information processing apparatus according to claim 1, wherein the information processing apparatus is configured to be attached to the other instruction. 6. An information processing method in which an agent, which is an execution entity on software, operates on a node connected to a network to perform information processing, wherein the agent is used for accessing a component arranged in the node. A step of storing first information representing a state of a component, a step of storing second information defining behavior of the execution subject, and a step of storing the first and second information. Creating a plan to be executed by the agent to achieve a given objective; and storing third information representing constraints that the plan must satisfy for node integrity; Determining whether the plan satisfies the constraint; and executing and executing the plan for the plan determined to satisfy the constraint. And a step of realizing the movement between the agent nodes, wherein the plan is created and determined also at the movement destination node. 7. A step for storing fourth information indicating how to generate a plan that satisfies the constraint, and when it is determined that the plan does not satisfy the constraint, the fourth information is stored. 7. The information processing method according to claim 6, further comprising: modifying a plan based on the information. 8. The information processing method according to claim 7, wherein one or more files are written to the node, information indicating which file is to be written to the node, information indicating the size of each file, Using the information indicating the priority between the files, the third information indicates a constraint on an allowable value of the amount of information that can be written to the node, and the fourth information indicates that a file having a lower priority is An information processing method characterized in that the plan is modified by excluding the plan. 9. The method according to claim 8, wherein the fourth information indicates that in the modification of the plan, the file having the lower priority is deleted from the files already written to the node. Information processing method. 10. The information processing method according to claim 8, wherein information indicating how to calculate the priority for each file is used. 11. A recording medium which records information processing software for performing information processing by using a computer to execute an agent which is an execution subject on software on a node connected to a network, comprising: Causes the computer to store first information representing a state of a component used for accessing a component disposed in the node, and to store second information defining behavior of the execution subject. Based on the first and second information, cause the agent to create a plan to be executed to achieve a given objective, and to represent a constraint that the plan must satisfy for node integrity. Is stored, and it is determined whether the plan satisfies the constraint. For, to realize the movement between the run and the agent of the plan node, in the destination node, a recording medium recording the information processing software, characterized in that to perform the creation and decision plan. 12. The software causes the computer to store fourth information indicating how to generate a plan that satisfies the constraint, and when it is determined that the plan does not satisfy the constraint, The recording medium according to claim 11, wherein the plan is modified based on the fourth information.