JP2001195372A - Agent service provision method and computer readable recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method for easily realizing a function for making a user able to enjoy information contents generated by exchange between agents matched with a utilizing location, a utilizing environment and a utilizing terminal, etc. SOLUTION: This method for providing the user with a service by using an agent system is provided. In the method, a service start request is received and user information is fetched first. Then, service scenarios are retrieved from a service scenario repository with the utilizing location of the user as a key and the service scenario to be executed is selected from the retrieved service scenarios based on the user information. Then, the selected service scenario is executed and the user is provided with the service. Also, the user is made to select the agent from the agents managed by an agent facilitator and the service scenario is generated through interaction with the user based on the selected agent.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method of realizing a user's request by communicating various agents operating on a plurality of distributed computers and providing various services. , A method of providing a service to a user using an agent system, and in particular, a function that allows a user to enjoy information generated by an exchange between agents according to a time, a place, a use environment, a use terminal, and the like. It relates to a method for easily realizing it.

[0002]

2. Description of the Related Art When a user requests a certain service by using a plurality of agents as a plurality of calculation processing processes that independently manage certain resources, information, and states operating on a plurality of computers, Agents are bound by certain constraints and work together to guide the results for that request.

In Japanese Patent Application No. 7-6142, agents do not cooperate with each other independently, but the process for managing the cooperative operation procedure is made independent as an agent.
The operation procedure is derived by a planning technique, or by describing the operation procedure in advance,
Implement services requested by users.

[0004]

However, in the conventional system, the feasibility can be evaluated only for the agent described in the operation procedure for realizing the service. Therefore, when the agent to be evaluated is stopped, when the function is changed, or when a new agent with the same function appears, the operation status of the agent changes. However, there was a problem that an appropriate service could not be provided.

Further, in the conventional system, when there is no operation procedure for providing a service desired by a user, there is a problem that a service scenario generation function for dynamically generating the operation procedure does not exist.

Further, the conventional system is divided into an agent that manages and executes an operation procedure and an element function agent that provides basic element functions of a service.
There is a problem in that a plan that reuses an existing plan cannot be generated.

The present invention has been made in view of the above points, and when a user selects a composite service combining a plurality of independent single services, services can be narrowed down according to the place of use, When there is no complex service, it is possible to create a complex service according to the user's intention by dynamically combining single services so that the user can enjoy the service that matches the situation and state. The aim is to provide a method.

[0008]

According to the first aspect of the present invention, there is provided a method for providing a service to a user by using an agent system, comprising the steps of: receiving a service start request and capturing user information; A search step of searching for a service scenario from a service scenario repository using a user's location as a key, a selection step of selecting a service scenario to be executed from the searched service scenarios based on user information, and a selected service Executing a scenario to provide a service to a user.

According to the present invention, a service scenario is selected using a use place and user information. Therefore, even if the service requested by the user is the same, different service scenarios are used depending on the use place and use environment. Can be used,
The convenience for the user is improved. According to a second aspect of the present invention, in the first aspect, the selecting step includes a step of evaluating execution conditions included in the service scenario using the user information, and a step of determining the service scenario according to the content of the evaluation. Selecting.

According to the present invention, the service scenario is given an execution condition, and the service scenario is selected by comparing the execution condition with the user information.
An appropriate service scenario can be selected according to the situation of the user.

According to a third aspect of the present invention, in the first aspect, the service scenario repository includes a tree-structured node using information indicating a spatial positional relationship as a key.
It has a configuration in which a list of service scenarios having keywords is placed.

According to the present invention, the service scenario repository has a structure based on a spatial positional relationship, so that a service corresponding to a use place of a user can be quickly searched. In addition, the provision of the service scenario repository facilitates reuse of the service scenario.

According to a fourth aspect of the present invention, in the third aspect, the searching step includes a step of searching a service scenario repository for a node that matches a place of use, and a step of extracting a service scenario from the searched node. And searching for a service scenario that is likely to be executed from the extracted service scenarios using the keyword or the service scenario name.

According to the present invention, first, a node that matches a place of use is searched, and thereafter, a service scenario that can be executed is narrowed down, so that a service scenario can be efficiently selected.

According to a fifth aspect of the present invention, in the first aspect, a step of retrieving an agent using a use place from an agent facilitator managing the agent using the use place or use time, and the searched agent And the step of generating a service scenario through interaction with the user based on the selected agent.

According to the present invention, it is possible to generate a service scenario according to the situation of the user.

According to a sixth aspect of the present invention, based on the fifth aspect, the service scenario repository includes a tree-structured node using information indicating a spatial positional relationship as a key.
Taking a configuration with a list of service scenarios, the method comprises the steps of: after a service scenario is generated, querying a user for a keyword and a service scenario name; and storing the service scenario name based on a place of use. A step of searching for a node in the scenario repository, and adding a keyword,
Adding a service scenario name and a service scenario file name.

According to the present invention, the generated service scenario can be stored in an appropriate location in the service scenario repository, and reuse is facilitated.

According to a seventh aspect of the present invention, in the third aspect, an item of a user or a group is provided in the list, and a user is restricted for a service scenario at the time of executing the search step. In the list, add an item for the last time the service scenario was executed,
Deleting from the list a service scenario for which a predetermined period has elapsed after execution.

According to the present invention, a specific service scenario can be provided only to a specific user or group. Further, unnecessary service scenarios can be deleted.

According to an eighth aspect of the present invention, there is provided a computer-readable recording medium recording a program for providing a service to a user in an agent system, wherein a procedure for receiving a service start request and taking in user information is provided. And a search procedure for searching for a service scenario from the service scenario repository using the user's usage location as a key, a selection procedure for selecting a service scenario to be executed from the searched service scenarios based on the user information, and a selection. And a program for causing a computer to execute a service scenario and provide a service to a user. The present invention relates to the above-described claim 1.
Has substantially the same function and effect as the invention described in (1).

According to a ninth aspect of the present invention, in the method of the eighth aspect, the selecting step includes a step of evaluating execution conditions included in the service scenario using user information, and a step of evaluating the execution condition included in the service scenario. Selecting a service scenario. The present invention has substantially the same operation and effect as the above-described second embodiment.

According to a tenth aspect of the present invention, the service scenario repository according to the eighth aspect, wherein the service scenario repository includes a list of service scenarios having a keyword in a tree-structured node using information indicating a spatial positional relationship as a key. This is the data that takes the configuration with. The present invention has substantially the same operation and effect as the above-described third embodiment.

According to an eleventh aspect of the present invention, in the method of the tenth aspect, the search step includes a step of searching a service scenario repository for a node matching a use place, and a step of extracting a service scenario from the searched node. And a procedure of searching for a service scenario that may be executed from the extracted service scenarios using the keyword or the service scenario name. The present invention has substantially the same operation and effect as the above-described invention.

According to a twelfth aspect of the present invention, in accordance with the eighth aspect, a procedure for searching for an agent using a use place from an agent facilitator that manages the agent using the use place or use time, and the searched agent And a program for causing a computer to further execute a procedure for allowing a user to select an agent from among the above, and a procedure for generating a service scenario through interaction with the user based on the selected agent. The present invention has substantially the same operation and effect as the above-described invention.

According to a thirteenth aspect of the present invention, in the twelfth aspect, the service scenario repository places a list of service scenarios in a tree-structured node using information indicating a spatial positional relationship as a key. A program for querying a user for a keyword and a service scenario name after a service scenario is generated, and a node of a service scenario repository for storing the service scenario name based on a place of use. Is recorded, and a procedure for causing a computer to execute a procedure of adding a keyword, a service scenario name, and a file name of a service scenario to a list in the searched node is recorded. The present invention has substantially the same operation and effect as the above-described invention.

According to a fourteenth aspect, in the tenth aspect, a user or group item is provided in the list, and a user is restricted for a service scenario at the time of executing the search step. In the list, add an item for the last time the service scenario was executed,
A program for causing a computer to execute a procedure of deleting a service scenario for which a predetermined period has elapsed after execution from the list is recorded. The present invention has substantially the same operation and effect as the above-described invention.

[0028]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. In this embodiment, an example in a multi-agent system will be described. A multi-agent system is an agent that provides various services running on a computer connected to a network and cooperates or cooperates with each other.
This is a system that assembles a complex service according to the user's request. First, an outline of the present embodiment will be described with reference to FIG.

As described above, this embodiment is a system realized on the multi-agent system 1, and the multi-agent system 1 is connected to the user terminal 5 via the network 3, for example. The user terminal 5 receives various services from the multi-agent system 1. Here, the multi-agent system 1 may be a system in which a plurality of computers are connected via a network, or a single computer. Various devices such as a computer and a telephone can be used as the user terminal. The network 3 can use the Internet, a telephone network, various data networks, or the like. A plurality of computers or a single computer executes a program that causes a computer to execute each process in an embodiment of the present invention described below, thereby realizing the process of the present invention. The program is, for example, CD-RO
M recorded on a recording medium such as M
-Loaded to a hard disk or the like via a ROM drive or the like and executed as appropriate. Further, a program for executing the processing of the present invention may be transmitted from one computer to another computer via a network.

In the present invention, as for the agents 7 which provide various single services, those which provide the same service are first classified, their input / output, communication means and procedures are unified, and further available places / time zones It is managed by a directory facilitator 9 described later together with the above. Further, in order to provide a composite service combining a plurality of services required by a user, a service scenario repository 13 for managing a service scenario 11 in which an operation procedure is described is provided. User location information acquired by the interface agent responsible for interacting with the user,
Evaluating and selecting a matching service scenario from the service scenario repository 13 using the user terminal environment information, the user's requested service name, the user's preference from the user agent that manages the user's profile, and the like, and executing it I do. This is performed by a service scenario interpreter 15 described later. If the service required by the user does not exist, obtain an agent that provides a usable single service from the agent management mechanism,
A service scenario for realizing the service is described and executed, or stored in a service scenario repository together with a keyword or the like characterizing the scenario. The generation of the service scenario is performed by a scenario automatic generation unit 17 described later.

FIG. 2 shows a description example of the service scenario. The service scenario 19 includes a description for requesting various processes to the agents 21 and 23 that provide a single service, combining the processing results, and assembling a certain service.

As shown in FIG. 2, the types of description are:
・ Process to send information to an agent that provides a service and obtain information, ・ Process information, ・ Evaluate and judge information, ・ Send message to agent without expecting a response is there.
Actually, these processes are described intricately.
In the service scenario 19, an execution condition 2 in which a condition as to whether or not to execute the service scenario is described.
5 are defined. In the example shown in FIG. 2, as the execution conditions, the time zone in which the scenario can effectively provide the service, the input / output device that can effectively enjoy the service, the information and internal state obtained from the user's profile and the interaction with the agent, The referenced evaluation expression is described.

The above service scenarios are stored in the service scenario repository 27. With the service scenario repository, the service scenario is managed on the basis of the location space, and the service scenario can be searched based on the location information.

The service scenario interpreter actually evaluates and executes the service scenario described above. The service scenario interpreter takes into account the profile of the user, the location and time of receiving the service, the terminal environment used, the influence of the user from other systems, and responds to the will of the user and the service provider. And select the service
Interpret and execute service scenarios.

FIG. 3 shows a service scenario interpreter 29.
Is shown. As shown in the figure, the service scenario interpreter 29 includes an execution condition evaluation unit 31 for evaluating the execution conditions of the service scenario, a scenario interpretation execution unit 33 for interpreting and executing the service scenario, and a shared area 35.
Having.

The common area 35 stores user profile information including profile information such as preferences, preferences, and behavior patterns of the user, and environment information of the user who is enjoying the service. As shown in FIG. 4, the user profile information 37 is taken from a user agent 39 which manages user information. The user agent itself also transfers that information to the interface agent 4 that is actually interacting with the user.
1 and a service agent 43 that manages sensors for detecting environmental information.

FIG. 5 shows a processing flow of a service scenario interpreter that executes a service scenario that is already prepared and provides the service to the user.

First, when there is a service start request from a user or a service (step S1), the user profile information of the user is taken into the shared area (step S1).
2). Next, based on the usage location information included in the user profile information, the service scenario repository
Search for possible service scenarios. In addition,
The use location information can be notified to the multi-agent system using various methods. For example, there is a method of inputting by a user when a user requests a service, automatically calculating the position of a user terminal, and notifying the multi-agent system of the position. Thereafter, the service start requester is checked (step S4). The subsequent processing procedure differs depending on the service request.

In the case of a pull-type service providing mode in which a user requests and receives a service, the execution condition of the retrieved service scenario is read, information in the shared area is compared with the execution condition, and execution is performed. Possible service scenarios are narrowed down (step S5). Finally, the user determines which one to select (step S6). How the user selects the service scenario depends on the method of selecting the service scenario on the spot or the method of registering the selection method in advance as a user profile and determining the service scenario to be executed. is there. Examples of the latter include a method in which the user presents the service scenario with the highest evaluation score to the user in the order specified by the profile and allows the user to select a plurality of service scenarios that the user wants to execute. There is a method to select a scenario that exceeds the threshold value specified in (1).

On the other hand, the service provider gives the user
In the case of the push type service providing type, which provides information by looking at the timing, the searched service scenario is compared with the service form, user input / output device information, and execution conditions, and the executable service scenario is narrowed down , And calculate an evaluation point. Among them, a service scenario exceeding the threshold specified in the user profile is selected (step S7). As a result, the plurality of selected service scenarios are individually evaluated by the scenario interpretation execution unit and sequentially executed (step S8). The processing of steps S2 to S7 is performed by the execution condition evaluation unit of the service scenario interpreter, and the processing of step S8 is performed by the scenario interpretation execution unit.

FIG. 6 shows the configuration of the scenario interpretation executing section 45. As shown in the figure, the scenario interpretation execution unit 45 has a scenario sentence interpretation unit 47, an execution unit 49, an internal memory 51, and a message generation / transmission / reception unit 53. Next, the operation of the scenario interpretation executing unit 45 will be described.

The selected service scenario is interpreted by the scenario sentence interpreting unit 47 in accordance with one of the four types of scenario descriptions shown in FIG.
Execute. The description is executed sequentially for all lines.
When processing or evaluating information, reference / update to a shared area in which a user profile or the like is managed or to a working internal memory 51 is performed. When transmitting a message to another agent, the message is generated and transmitted by the message generation / transmission / reception unit 53, and the message is transmitted via a communication protocol. When a reply needs to be received, a message response is received and the result is returned to the execution unit 49.

Next, the process of searching for the service scenario described in FIG. 5 from the service scenario repository (the process of step S3) will be described in detail with reference to FIGS. 7 and 8.

FIG. 7 is a diagram showing an example of the management structure of the service scenario repository. As shown in the figure, the service scenario repository has a structure in which a list structure with keywords as indexes hangs on a tree-structured node with information indicating spatial positional relationships such as addresses, latitude and longitude, track routes, etc. Take. Here, the vocabulary serving as the index of the keyword list may be one or more. Also,
The keyword list 57 of the service scenario common to all the spaces hangs at the top node 55. First
Below the top (top) node, nodes of the spatial position expression are expanded.

In the node expansion method, a broader regional expression is a higher-level node based on the inclusion relation of places. For example, as shown in FIG. 7, “hill of light” 59 and “Kurihama” 6
1. “Tsukui” 63 belongs to “Yokosuka City” 65, “Yokosuka City” 65 and “Yokohama City” 67 belong to “Kanagawa Prefecture” 69, etc., and expressions based on address expressions such as “Shinagawa Station” 71
And expressions based on the relationship between stations such as “Yokohama Station” 73 and “Kurihama Station” 75 and routes such as “Keihin Kyuko Line” 77.

The keyword list hanging at each node is managed by a pointer storing a keyword, a service scenario name, and a service scenario. Here, the pointer to the service scenario is indicated by a file name.

FIG. 8 is a flowchart showing a process of searching for a service scenario from the service scenario repository. The process of searching for a service scenario from the service scenario repository will be described with reference to FIG.

First, a search is made for a node whose name matches the name of the place of use based on the place of use (step S11). Regarding the match determination method at the time of search, whether to use perfect match, forward match, partial match, or whether a service scenario hanging on a higher node of a node when a certain node is searched is also searched Can be selected according to each spatial position expression method. Further, when there is no matching node, a method of changing the use place information and performing a search again can be incorporated.

That is, it is checked whether or not the use place needs to be changed (step S12).
The use location expression is changed with reference to the spatial information mapping table (step S13). It is checked whether or not the use place expression has been changed (step S14). If the change has been made, the service scenario repository is searched again based on the converted use place expression (step S1).
1). For example, when "Nobi, Yokosuka City, Kanagawa Prefecture" is designated as a use place, the use place expression can be converted with reference to the spatial information mapping table, and the service scenario repository can be searched again based on the converted use place expression. Thereafter, a user scenario is extracted from the searched node (step S15).

After repeating the processing of steps S11 to S15 by the number of place classifications, duplicated user scenarios are removed from the extracted user scenarios (step S1).
6). Then, for a plurality of service scenarios from which duplicates have been removed, a corresponding service scenario is extracted using a character string matching or the like with respect to a specified keyword or scenario name (step 17). The specification of a keyword or a scenario name is performed, for example, when a service is requested. The result is returned to the requestor.

As described above, if the desired service scenario is stored in the service scenario repository, the user can select it and enjoy the service. On the other hand, if the desired service scenario does not exist, the above-described scenario automatic generation unit generates and executes an appropriate scenario while interacting with the user.

FIG. 9 shows the configuration of a scenario automatic generation unit 79 that dynamically creates and executes a user scenario. As shown in the figure, the scenario automatic generation unit 79 includes an agent extraction unit 81 and a matching processing unit 83. The operation is as follows.

First, the agent extracting unit 81 extracts available service agents from the directory facilitator 85 using the location information of the user. Here, the directory facilitator 85 manages the operation status of the service agent providing the single service. For example, when the use place is Kurihama Station, the Kurihama Station Timetable Agent to the Fast Food Agent are searched as the agent candidates from the Kurihama Station Timetable Agent to the Yokohama Chinese Recommendation Agent managed by the directory facilitator.

Next, the selected service agents (agent candidates 87) are transferred to the scenario matching processing unit 83.
, A service scenario is dynamically generated through interaction between an agent scenario possessed by an agent and a user. The generated service scenario is sequentially interpreted and executed by the scenario interpretation execution unit of the service scenario interpreter. The service scenario is generated by the scenario automatic generation unit as an ad hoc service scenario, and is executed by the scenario interpretation execution unit.

FIG. 10 is a diagram showing a description example of the agent scenario described in FIG. The agent scenario consists of input processing from the user for arguments required for receiving the service to the service agent, inquiry processing to the service agent, and output processing for presenting the output of the service result to the user. I have.
The input processing from the user can avoid direct interaction with the user by passing through the proxy agent of the user. For example, if a user agent such as that shown in FIG. 4 is used, it is possible to avoid repeated inquiries for the same argument name and to make a proxy response using a stored profile.

There are several methods for processing in the scenario matching processing unit 83 depending on the type of service to be obtained.
11 and 12 show flowcharts of processing in the scenario matching processing unit 83.

FIG. 11 is a flowchart of a process when it is desired to customize an information providing service requiring a small number of arguments. In this case, the user selects agents to be used collectively.

That is, as shown in the figure, first, the user specifies the order of use from the agent candidate list (step S21). Next, the scenario matching processing unit acquires the agent scenario of the selected agent (Step S22). Then, a required argument name list is presented, and the user is inquired about how to input (step S23). A service scenario is generated based on the agent scenario and the argument input method thus obtained (step S24).

FIG. 12 is a flowchart of a process for generating a service scenario in which a plurality of agents are related to each other. In this case, the agent that finally provides the desired service is selected, and the agent required to obtain the required argument therefrom is selected by a formula based on a potato.

As shown in FIG. 12, first, the user selects an agent returning a desired value from agent candidates (step S31). Next, the agent scenario of the selected agent is obtained (step S3).
2), how to obtain necessary arguments is selected (step S33). Here, when obtaining an argument using an agent, the user selects an agent that returns the value of the argument from the agent candidates (step S34). The processes in steps S32 to S34 are repeated until a method for acquiring a necessary argument is determined. After step S33, if there are no unsolved arguments, a service scenario is generated based on the agent scenario and the argument input method (step S35).

Next, a specific example of the processing of the scenario matching processing unit will be described with reference to FIGS. FIG.
FIG. 14 is a diagram for explaining a specific example in the case described in FIG. 11, and FIG. 14 is a diagram for explaining a specific example in the case described in FIG.

The specific examples shown in FIGS. 13 and 14 are examples of providing a service for displaying a map from a restaurant near "Kurihama Station" where the user is currently located.

In both cases, prior to the scenario matching process, the directory facilitator uses the information of “Kurihama Station”, which is the place where the user accessed the system, as a key to search for a restaurant search agent, fast food agent, and Kurihama station. The timetable agent and the route guidance agent are searched and presented to the user.

In FIG. 13, the user selects a store to which he / she wants to go and, because he / she wants to know the route to that store, selects a restaurant search agent and a route guidance agent.
92 (corresponding to steps S21 and S22 in FIG. 11). A service scenario obtained by simply combining these agent scenarios is a service scenario 94 after the combination.

In this service scenario 94, there are many arguments that need to be inquired of the user. Therefore, in order to determine how to process them, arguments are extracted and the solution is determined by interacting with the user (step S23). The result is calculated as the combined service scenario to obtain the matched service scenario 96 (step S24). As shown in the figure, for example, the argument loc
Is set to use location information for the argument cat
Is input by the user. As a result, in the service scenario after the matching, the user location information is set in loc, and the input value from the user when inquiring about the genre is set in cat.

On the other hand, in the case shown in FIG. 14, when a guide agent that provides a guide that the user ultimately wants to obtain is selected from the agent list retrieved from the directory facilitator, the agent of the guide agent is selected. The scenario 98 is acquired (corresponding to steps S31 and S32 in FIG. 12).

Then, the user is inquired about how to resolve the necessary arguments (step S33). Here, the method of calculating the current location (loc), the location (dest) of the restaurant, and the route (meth) is unresolved. Current location (loc)
Uses the use place information, the restaurant place (dest) uses the restaurant search agent (corresponding to step S34), and the route calculation method (meth) selects the means input by the user. Here, the agent scenario 100 of the restaurant search agent is acquired, and unresolved arguments are again identified, and it is found that they are the current location (loc) and the genre (cat) of the restaurant. Further, the processing of determining the processing method of these unresolved arguments is repeated (corresponding to repeating the processing of steps S32 to S34 in FIG. 12). In this example, loc is set to the user location information, and cat is set by the user. In FIG. 14, it is determined that there is no unresolved argument, and the results up to that point are collectively referred to as a service scenario 102 after matching.

Now, in the above agent system, the dynamically generated service scenario is reused.
Alternatively, in order to delete a service scenario that is no longer needed from the service scenario repository, the service scenario is combined with the execution conditions such as the terminal environment, usage time, and location used by the user, and keywords that characterize the service scenario. It is possible to manage. This is performed by a service scenario manager described later. For example, when a user deletes an existing service scenario, the service scenario is specified from the service scenario repository using the keyword specified by the user and information from the interface agent or the user agent as a key, and is deleted.

For a service scenario that has already been created, the service scenario
User restrictions such that only the creator can be referred to, or anyone can use, or only a person belonging to a specific group can access, can be set, and execution / control can be performed. This is performed by an access manager described later. That is, by managing both the service scenario and whether or not a user or a group can be accessed, it is possible to limit the use range.

Further, by managing the time at which the service scenario was last used, it is possible to monitor a service scenario that has become unnecessary or is hardly used. This is performed by a garpage manager described later. In other words, by managing the service scenario together with the last execution time, it becomes possible to find a service scenario that is no longer used or becomes unnecessary and delete it.

FIG. 15 shows the service scenario manager 104, access manager 106, garbage manager 108, and service scenario repository 110.
FIG. The service scenario manager 104 stores or deletes an ad hoc service scenario as shown in FIG. 9 in the service scenario repository 110 so that it can be reused. The access manager 106 manages the service scenario repository 11
When a process for making the service scenario stored in “0” available to a limited user is performed, the service scenario has a function of finding an unnecessary service scenario and deleting it. The garbage manager 108 monitors a service scenario.

FIG. 16 is a flowchart describing a process performed by the service scenario manager until the service scenario generated after the service scenario automatic generation process is stored in the service scenario repository. The processing will be described with reference to FIG.

First, a service scenario is generated by the service scenario automatic generation unit (step S41). As described above, the service scenario is generated as an ad hoc service scenario, and is executed by the scenario interpretation execution unit (Step S42). Next, the service scenario manager determines whether or not to store the generated service scenario (Step S43), and if not, ends the processing.

When storing a service scenario, the user first inquires of a scenario name and a keyword (step S44). The keyword and the scenario name may be created by combining the service agent names constituting the scenario. Then, a node to be stored is searched from the service scenario repository (step S4).
5). Here, if the use place condition needs to be changed, the use place condition is changed with reference to the spatial information mapping table, and the service repository node is searched again (steps S46, S47, S45). When the node is found, the service scenario with a unique name
It is stored in the next medium (step S48). And the address, keyword, service scenario name, usage time,
And the file name are stored in the keyword list hanging at the node (step S49).

FIG. 17 is a flowchart showing a process of deleting a service scenario determined to be unnecessary by the user. As shown in the figure, the service scenario manager first inquires of the user about use place information, a keyword, and a scenario name in order to select a deleted service scenario (step S51). Based on the result, the service scenario repository is searched, and a service scenario that may be applicable is searched. That is, for all nodes in the service scenario repository, a search is made for a user scenario and a node whose use time, keyword, scenario name, and the like match. This search method is
This is the same as the method described with reference to FIG.

The result is presented to the user again to allow the user to select a service scenario to be deleted (step S53). Then, the service scenario to be deleted is deleted from the keyword list of the corresponding node (steps S54 and S55). If not, an inquiry is made as to whether or not the next service list can be deleted (step S).
54, S53). The processing of steps S53 to S55 is repeated for all the searched service scenarios,
The deletion processing ends.

The access control relating to the service scenario is performed by the access manager 106 shown in FIG. Specifically, the following processing is performed.

As shown in FIG. 18, items in the keyword list managed in the service scenario repository include:
By adding attributes of user and group, the access manager examines the search results from the service scenario repository, and removes service scenarios with user restrictions from the search results. I have. The keyword list shown in FIG.
This is an example having a use time (the item of "hour" in the figure).

As shown in FIG. 18, to delete a service scenario determined to be unnecessary, the keyword list has the last execution time of the service scenario. The garbage manager 108 shown in FIG. 15 periodically checks the service scenario stored in the service scenario repository, and deletes a service scenario whose predetermined time has passed from the scenario list.

The present invention is not limited to the above embodiment, but can be variously modified and applied within the scope of the claims.

[0081]

As described above, according to the present invention, it is possible to narrow down the services according to the place such as the place of use and the time of use, so that the usability of the user can be improved.

Further, since a composite service desired by the user can be created by combining a plurality of single services, a service can be provided according to the user's intention.

Further, since the composite service considered by the user can be stored and reused, customization can be performed under the initiative of the service provider, and effects such as an improvement in service productivity can be achieved.

[0084]

[Brief description of the drawings]

FIG. 1 is a schematic configuration diagram of an embodiment according to the present invention.

FIG. 2 is a diagram illustrating a description example of a service scenario and an execution condition.

FIG. 3 is a configuration diagram of a service scenario interpreter.

FIG. 4 is a diagram for explaining a method of acquiring shared area information.

FIG. 5 is a flowchart showing processing of a service scenario interpreter.

FIG. 6 is a configuration diagram of a scenario interpretation execution unit.

FIG. 7 is a management structure diagram of a service scenario repository.

FIG. 8 is a flowchart of a process of searching a service scenario repository.

FIG. 9 is a configuration diagram of a scenario automatic generation unit.

FIG. 10 is a diagram showing an example of an agent scenario description.

FIG. 11 is a flowchart of a scenario matching process.

FIG. 12 is a flowchart of a scenario matching process in another example.

FIG. 13 is a diagram for specifically explaining a scenario matching process;

FIG. 14 is a diagram for specifically explaining another example of scenario matching processing;

FIG. 15 is a diagram showing the relationship between a service scenario manager, an access manager, a garpage manager, and a service scenario repository.

FIG. 16 is a flowchart of a storing process of the service scenario manager.

FIG. 17 is a flowchart of a service scenario deletion process.

FIG. 18 is an expanded view of the structure of a keyword list.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 1 Multi-agent system 3 Network 5 User terminal 7, 21, 23 Agent 9 Directory facilitator 11, 19 Service scenario 13, 27 Service scenario repository 15, 29 Service scenario interpreter 17 Scenario automatic generation unit 25 Execution condition 31 Execution condition evaluation unit 33 Scenario interpretation execution unit 35 Shared area 37 User profile information 39 User agent 41 Interface agent 43 Service agent 45 Scenario interpretation execution unit 47 Scenario sentence interpretation unit 49 Execution unit 51 Internal memory 53 Message generation / transmission / reception unit 55, 59-77 Node 57 Keyword List 79 Scenario automatic generation unit 81 Agent extraction unit 83 Matching processing unit 85 Directory facilitator 87 Jento candidate 90,100 restaurants search agent Agents scenario 92, 98 after service scenarios 96 and 102 harmonization after agent scenario 94 binding directions Agent service scenario 104 service scenario manager 106 access manager 108 garbage Manager 110 services scenario repository

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Masaki Minami 2-3-1 Otemachi, Chiyoda-ku, Tokyo Nippon Telegraph and Telephone Corporation (72) Inventor Miyazaki Yasuhiko 2-3-3 Otemachi, Chiyoda-ku, Tokyo No. 1 Nippon Telegraph and Telephone Corporation F-term (reference) 5B045 GG01

Claims (14)

[Claims] 1. A method for providing a service to a user using an agent system, comprising the steps of: receiving a service start request and capturing user information; and a service scenario from a service scenario repository using the user's use location as a key. A selecting step of selecting a service scenario to be executed from the searched service scenarios based on the user information; and providing a service to the user by executing the selected service scenario. A method comprising: 2. The method according to claim 1, wherein the selecting step includes a step of evaluating an execution condition included in the service scenario using user information, and a step of selecting a service scenario according to the content of the evaluation. the method of. 3. The method according to claim 1, wherein the service scenario repository has a configuration in which a list of service scenarios having a keyword is placed in a tree-structured node using information indicating a spatial positional relationship as a key. 4. The search step includes a step of searching a service scenario repository for a node matching a use location, a step of extracting a service scenario from the searched node, and a keyword or service scenario name from the extracted service scenarios. Retrieving a service scenario that may be performed using the service scenario. 5. A step of retrieving an agent using a use place from an agent facilitator that manages an agent using a use place or use time, a step of allowing a user to select an agent from the searched agents, Generating a service scenario through interaction with a user based on the generated agent. 6. The service scenario repository has a configuration in which a list of service scenarios is placed in a tree-structured node using information indicating a spatial positional relationship as a key. Later, querying the user for a keyword and a service scenario name; searching for a node in the service scenario repository storing the service scenario name based on the place of use; Adding a scenario name and a service scenario file name. 7. A step of providing an item of a user or a group in the list, applying a user restriction to a service scenario at the time of executing the search step, and an item of a time at which the service scenario was last executed in the list. And removing service scenarios for which a predetermined period of time has elapsed since execution from the list. 8. A computer-readable recording medium in which a program for providing a service to a user in an agent system is recorded, wherein a procedure for receiving a service start request and taking in user information is provided. A search procedure for searching for a service scenario from the service scenario repository using as a key, a selection procedure for selecting a service scenario to be executed from the searched service scenarios based on the user information, and executing the selected service scenario And a computer-readable recording medium storing a program for causing a computer to execute a procedure for providing a service to a user. 9. The method according to claim 8, wherein the selecting step includes a step of evaluating execution conditions included in a service scenario using user information, and a step of selecting a service scenario according to the content of the evaluation. A computer-readable recording medium on which the program is recorded. 10. The service scenario repository according to claim 8, wherein the service scenario repository is a data having a configuration in which a list of service scenarios having a keyword is placed in a tree-structured node using information indicating a spatial positional relationship as a key. A computer-readable recording medium on which the program is recorded. 11. The search procedure includes a step of searching a service scenario repository for a node matching a use place, a step of extracting a service scenario from the searched node, and a keyword or service scenario name from the extracted service scenario. 11. A computer-readable recording medium recording the program according to claim 10, further comprising: a step of searching for a service scenario that can be executed by using the program. 12. A procedure for retrieving an agent using a use place from an agent facilitator that manages an agent using a use place or a use time, a procedure for allowing a user to select an agent from the searched agents, 9. A computer-readable recording medium recording a program according to claim 8, further comprising the step of causing a computer to further execute a procedure of generating a service scenario through interaction with a user based on the agent. 13. The service scenario repository,
This is data that has a configuration in which a list of service scenarios is placed in a tree-structured node with information indicating a spatial positional relationship as a key, and the program provides a keyword and a service to a user after the service scenario is generated. A procedure for querying the scenario name, a procedure for searching for a node in the service scenario repository that stores the service scenario name based on the place of use, and a keyword, a service scenario name, and a file name for the service scenario in a list in the searched node. 13. A computer-readable recording medium on which the program according to claim 12 is recorded, which causes the computer to execute the steps of: 14. A procedure for providing an item of a user or a group in the list, and restricting a user to a service scenario at the time of executing the search step, and an item of a time at which the service scenario was last executed in the list. 11. A computer-readable storage medium storing a program according to claim 10, wherein the program further comprises: executing a procedure of deleting a service scenario for which a predetermined period has elapsed after execution from the list.