JP7060985B2 - Scenario creation support system and scenario creation support method - Google Patents

Description

The present invention relates to a scenario creation support system and a scenario creation support method, and is suitable for being applied to a scenario creation support system and a scenario creation support method that support the creation of a scenario for dialogue.

Conventionally, a system for interacting with a user using a chatbot or the like is known. In order to realize a natural dialogue in such a dialogue system, it is necessary to ask an answer according to the user's utterance and the next question according to the user's utterance.

Therefore, a technique has been proposed that supports the creation of a scenario for dialogue, which is composed of an answer according to a user's utterance and the following question (for example, Patent Document 1).

The scenario creation support device disclosed in Patent Document 1 manages a pair of an input (utterance) from a user and an output (answer or next question) from a system as a record by using a dialogue scenario specification table. For input, describe the key words of input and the scenario in which the input is valid, and for output, describe the utterance sentence from the system and the scenario to be transitioned to next. In this way, the scenario creation support device disclosed in Patent Document 1 is a scenario composed of a plurality of inputs and outputs by using a table capable of describing a scenario in which an input is valid and a scenario in which the next transition occurs. Even so, it is possible to add inputs and outputs on a record-by-record basis at any time.

Japanese Unexamined Patent Publication No. 2003-280678

As described above, the scenario creation support device disclosed in Patent Document 1 facilitates the addition of inputs and outputs in the scenario. However, since it does not support the creation of a scenario while grasping the entire scenario, "unnecessary questions" are added to the scenario when creating a scenario with the purpose of executing a specific task such as store information. There was a possibility that it would end up.

Here, the "unnecessary question" means an unnecessary question or a contradictory question when the background of the dialogue in the scenario is taken into consideration. Specifically, for example, as a result of asking the user whether he likes Japanese food from the system, after answering that he does not like it, the system asks the user whether he likes soba, which is one of the Japanese foods. A question like asking is equivalent. In other words, the question asking the likes and dislikes of soba, which is one of the Japanese dishes, is a practically meaningless and unnecessary question even though the user replies that he does not like Japanese food. This is a question that contradicts the circumstances. In the scenario creation support device disclosed in Patent Document 1, such "unnecessary questions" may be added to the scenario, which may make it difficult to form a natural dialogue.

The present invention has been made in consideration of the above points, and by presenting inconsistent parts in the scenario, it is necessary to support the creation of a scenario (in other words, a consistent scenario) in which unnecessary questions are not mixed. We are trying to propose a scenario creation support system and a scenario creation support method that can be used.

In order to solve such a problem, the present invention is a scenario creation support system for verifying an interactive scenario configured by connecting a plurality of scenario parts, and can be used in the scenario parts according to user input. As attribute information related to a literal, one of an attribute information definition that defines a plurality of first resources indicating attributes and a reference relationship between the attributes and the literal corresponding to the literal and defined in the attribute information definition. In the scenario created by connecting the resource group of the second resource that refers to the first resource, the attribute information registration unit that registers in the storage device, and the plurality of scenario parts using the literal. On the other hand, in the order of connection of the scenario parts, the reference destination resource referred to by each scenario part is specified based on the registered contents in the attribute information of the second resource corresponding to the literal used for the scenario part. , A scenario verification unit that determines a scenario component that contradicts the background of the dialogue of the scenario by comparing the identified referenced resources, and a selection is selected for the plurality of scenario components constituting the scenario. A first scenario component indicating a desired question and a second scenario component indicating a selection result for the question are included, and the scenario verification unit verifies the plurality of scenario components constituting the scenario in the order of concatenation. , The referenced resource identified for the first scenario component to which the second scenario component indicating a negative selection result is concatenated is stored in a non-selected resource array, and is behind the second scenario component. When the referenced resource identified for the other first scenario component linked to is stored in the non-selected resource array, the other first scenario component is the contradictory scenario component. A scenario creation support system for determining that is provided.

Further, in order to solve such a problem, in the present invention, it is a scenario creation support method by a scenario creation support system for verifying an interactive scenario configured by connecting a plurality of scenario parts, and it is a scenario creation support method according to user input. As attribute information related to literals that can be used in the scenario component, the scenario creation support system defines attribute information definitions that define a plurality of first resources indicating attributes and a reference relationship between the attributes, and the literal corresponding to itself. The attribute information registration step for registering the resource group of the second resource that has the above and refers to any of the first resources defined in the attribute information definition in the storage device, and the scenario creation support system. For the scenario created by concatenating the plurality of scenario parts using the literal, the referenced resource referred to by each scenario part is used for the scenario part in the order of concatenating the scenario parts. By specifying the second resource corresponding to the literal based on the registered contents in the attribute information registered in the attribute information registration step and comparing the specified referenced resources, the dialogue process of the scenario can be obtained. The plurality of scenario parts constituting the scenario include a scenario verification step for determining inconsistent scenario parts, a first scenario part indicating a question for which selection is requested, and a second scenario component indicating a selection result for the question. The scenario component is included, and in the scenario verification step, the scenario creation support system verifies the plurality of scenario components constituting the scenario in the order of concatenation, and the second scenario component showing a negative selection result. For the first scenario component to which the above-specified reference resource is stored in the non-selected resource array, and for another first scenario component to be concatenated after the second scenario component. Provided is a scenario creation support method for determining that another first scenario component is the contradictory scenario component when the identified referenced resource is stored in the non-selected resource array .

According to the present invention, it is possible to support the creation of a scenario (a consistent scenario) in which unnecessary questions are not mixed.

It is a block diagram which shows the structural example of the scenario creation support system which concerns on one Embodiment of this invention. It is a figure for demonstrating the concept of attribute information. It is a figure (the 1) which shows the screen composition example of the attribute information management screen. It is a figure (the 2) which shows the screen composition example of the attribute information management screen. It is a flow chart which shows the flow of scenario creation support. It is a figure which shows the configuration example of the scenario creation screen. It is a flowchart which shows the processing procedure example of a scenario component verification.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. However, the present invention is not construed as being limited to the description of the embodiments shown below, and its specific configuration can be changed without departing from the idea or purpose of the present invention.

Further, in the configuration of the embodiment described below, the same reference numerals may be commonly used between the drawings for the same parts or the parts having the same functions, and the duplicated description may be omitted. Further, the notations of the first, second, third and the like in the present specification and the like are attached for selecting the constituent elements, and do not necessarily limit the number or order. Further, the numbers for identifying the components are used for each context, and the numbers used in one context do not always indicate the same composition in the other contexts. Further, it does not prevent the component identified by a certain number from functioning as the component identified by another number.

Further, the position, size, shape, range, etc. of each configuration shown in the drawings and the like may not represent the actual position, size, shape, range, etc., in order to facilitate understanding of the invention. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings and the like. Further, in each drawing, control lines and information lines are shown as necessary for explanation, and not all control lines and information lines are necessarily shown in the product. In practice it may be considered that almost all configurations are interconnected.

In this specification, various programs executed in the processing unit of the information processing apparatus, or a part thereof, are referred to as "parts", "units", "means", "functions", or "modules". It may be called. Further, the configuration of the embodiment may be configured by a single computer, or an arbitrary part of an input device, an output device, a processing device, and a storage device may be configured by another computer connected via a network. It may be configured. Further, in the embodiment, the function equivalent to the function configured by the software can be realized by the hardware such as FPGA (Field Programmable Gate Array) and ASIC (Application Specific Integrated Circuit).

(1) Configuration of Scenario Creation Support System FIG. 1 is a block diagram showing a configuration example of a scenario creation support system according to an embodiment of the present invention. As shown in FIG. 1, the scenario creation support system 1 is configured by connecting a scenario creation server 10 and one or more user terminals 20 via a network 30 such as the Internet, and can be used in a dialogue scenario. It is a service system that supports the creation of scenarios (consistent scenarios) that do not include unnecessary questions based on attribute information related to items. In this specification, scenario parts that cause "unnecessary questions" in a scenario are referred to as "inconsistent scenario parts" or "inconsistent scenario parts", and such scenario parts are referred to as "inconsistent scenario parts". By presenting, the creation of a "consistent scenario" is supported.

In FIG. 1, assuming that the operation of each user terminal 20 by a plurality of users is reflected in the scenario creation support in the scenario creation server 10, the scenario creation server 10 and the user terminal 20 are connected via the network 30. Although it is a separate configuration to be connected, the configuration of the scenario creation support system 1 according to the present embodiment is not limited to this. For example, the scenario creation server 10 and the user terminal 20 may be integrated, and the user may directly perform the operation related to the scenario creation support in the integrated device or the like.

First, the detailed configuration of the scenario creation server 10 will be described. The scenario creation server 10 can be realized by a general server device, and as shown in FIG. 1, a control unit 11, a network interface unit 12, a web service providing unit 13, an attribute information registration unit 14, and an attribute information storage unit. A unit 15, a scenario verification unit 16, and a verification rule storage unit 17 are provided. Further, each of these parts is connected by a BUS (bus) 18 or the like.

The network interface unit 12 is composed of, for example, a network card or the like, and has a communication function. Specifically, the network interface unit 12 transmits the IP packet transferred by the control unit 11 to the user terminal 20 via the network 30, and also receives the IP packet received by the scenario creation server 10 via the network 30. Transfer to the control unit 11.

The web service providing unit 13 describes data described in a format (for example, HTML (HyperText Markup Language)) that can be displayed on the user terminal 20 on the user terminal 20 via the network 30, XML (Extensible Markup Language), and JSON (JSON). Sends data described in a format such as JavaScript (registered trademark) Object Notation). Further, the web service providing unit 13 receives information such as operation contents on the web browser of the user terminal 20 via the network 30, and based on the received information, the attribute information registration unit 14, the scenario verification unit 16, etc. Is executed. The web service providing unit 13 is, for example, a program having the above-mentioned web service function.

The attribute information registration unit 14 receives information such as operation details on the web browser of the user terminal 20 via the network 30, and based on the received information, attributes the attribute information related to the items that can be used in the scenario. This is a program having a function of registering in the information storage unit 15.

The attribute information storage unit 15 is a storage unit composed of, for example, an HDD (Hard Disk Drive) or the like, and stores a part or all of the attribute information used for the processing executed by the scenario verification unit 16. The attribute information storage unit 15 is provided by a plurality of storage units having different storage methods such as an RDB (Relational DataBase), a file server, and a KVS (Key-Value Store) according to the size and format of the data to be stored. It may be configured. Further, a part or all of the data equivalent to the data stored in the attribute information storage unit 15 may be provided by a plurality of other servers connected to the network 30.

The scenario verification unit 16 receives the scenario created on the web browser of the user terminal 20 via the network 30, and uses the attribute information recorded in the attribute information storage unit 15 for the received scenario. It is a program that has a function to verify the existence of inconsistent parts of the scenario.

The verification rule storage unit 17 is a storage unit composed of, for example, an HDD or the like, and stores a part or all of a program when the scenario verification unit 16 executes processing and a rule of a rule engine that performs branch processing. Similar to the attribute information storage unit 15, the verification rule storage unit 17 is composed of a plurality of storage units having different storage methods such as RDB, file server, KVS, etc., depending on the size and format of the data to be stored. May be. Further, a part or all of the data equivalent to the data stored in the verification rule storage unit 17 may be provided by a plurality of other servers connected to the network 30.

The control unit 11 is composed of, for example, a CPU (Central Processing Unit) or the like, and controls the entire scenario creation server 10 by executing a program of each unit of the scenario creation server 10 described above.

Specifically, the control unit 11 executes the program of the web service providing unit 13, so that the web service that can be used by the user terminal 20 is provided. The details will be described later, but the "attribute information management screen" (see FIGS. 3 and 4) used for registering attribute information and the "scenario creation screen" (see FIG. 6) used for creating a scenario. Such a web service screen is provided by the function of the web service providing unit 13.

Further, when the control unit 11 executes the program of the attribute information registration unit 14, the attribute information related to the items that can be used in the scenario is registered in the attribute information storage unit 15. Further, the control unit 11 stores a part or all of the attribute information used in the execution of the program of the scenario verification unit 16 in the attribute information storage unit 15. Further, the control unit 11 stores a part or all of the rules of the rule engine used in the execution of the program of the scenario verification unit 16 in the verification rule storage unit 17. Then, the control unit 11 executes the program of the scenario verification unit 16 to verify the presence or absence of inconsistent parts of the scenario.

In the scenario creation server 10, each of the above functions provided by executing a program may be realized by hardware such as an LSI. Further, each component shown in FIG. 1 does not need to be physically separated, and one component may also serve as another component. Further, in FIG. 1, illustration of an input device, an output device, and the like provided in a general server is omitted.

Next, the detailed configuration of the user terminal 20 will be described. The user terminal 20 can be realized by a general computer, and as shown in FIG. 1, includes a control unit 21, a network interface unit 22, an input unit 23, and an output unit 24. Further, each of these parts is connected by a BUS (bus) 25 or the like.

The network interface unit 22 is composed of, for example, a network card or the like, and has a communication function. Specifically, the network interface unit 22 transmits the IP packet transferred by the control unit 21 to the scenario creation server 10 via the network 30, and also transmits the IP packet received by the user terminal 20 via the network 30. Transfer to the control unit 21.

The input unit 23 transmits an input from the outside to the control unit 21, and is composed of a keyboard, a mouse, and the like.

The output unit 24 outputs information from the control unit 21 to the outside, and is composed of a display, a printer, and the like.

The control unit 21 is composed of, for example, a CPU or the like, and controls the entire user terminal 20 including each unit of the user terminal 20 described above by executing a program or the like. Specifically, for example, the control unit 21 receives input information from the input unit 23 and sends output information to the output unit 24. In the user terminal 20, each of the above functions provided by executing a program may be realized by hardware such as an LSI.

(2) Attribute information As described above, the scenario creation support system 1 according to the present embodiment has inconsistent parts (scenario parts) of the scenario based on the attribute information related to the items that can be used in the dialogue scenario. ) Is presented. Hereinafter, the concept of such attribute information and the registration method will be described in detail.

FIG. 2 is a diagram for explaining the concept of attribute information. FIG. 2 shows a conceptual diagram of the attribute information 100 as an example of the attribute information stored in the attribute information storage unit 15 of the scenario creation server 10. In the example of FIG. 2, RDF (Resource Description Framework) / RDFS (RDF Schema) is used as the data description format of the attribute information 100, and the content of the data is represented in a graph format.

The attribute information storage unit 15 stores the attribute information definition and the resource group that refers to the attribute information definition as the attribute information related to the items that can be used in the scenario. In the case of FIG. 2, the attribute information 100 is composed of the attribute information definition 110 shown in the range 100a and the resource group 120 shown in the range 100b. The attribute information definition 110 defines each resource of the resource group 120 (indicated by an ellipse in the figure) and the relationship between each resource (indicated by a line with an arrow in the figure).

According to FIG. 2, in the attribute information definition 110 (range 100a), a class 111 showing the concept of a class (Class) and a class 112 showing the concept of a property (Property) are shown. The attribute information definition 110 includes a resource 113 called "ex: store" whose "rdf: type" is "Class" and a resource 114 called "ex: genre name" whose "rdf: type" is "Class". And there is a resource 115 called "ex: genre" where "rdf: type" is "Property". Note that "rdf:" and "ex:" are identifiers for representing namespaces.

Further, as shown in FIG. 2, a resource 116 called "ex: retail store" whose "rdf: type" is "Class" and an "ex: restaurant" whose "rdf: type" is "Class". The resource 117 is a subclass (rdf: subClassOf) of the resource 113 called “ex: store”.

In addition, the resource 114 "ex: genre" has the resources 117 and 114 "ex: restaurant" and "ex: genre" in "rdfs: domain", and the resource 115 "ex: genre name" is "rdfs". Have in: range. Note that "rdfs:" is an identifier for representing a namespace.

On the other hand, the resource group 120 (range 100b) includes "http: //.../ ex1", "http: //.../ ex2", "http: //.../ ex3", and "", respectively. Resources 121-126 "http: //.../ ex4", "http: //.../ ex5", and "http: //.../ ex6" are shown. In the range 100b, literals 131 to 136 such as "Chinese", "Chinese Totsuka", "Japanese food", "Soba", "Sushi", and "Totsuka soba" correspond to each resource 121 to 126. It is shown.

Here, for each of the resources 121 to 126, the relationship defined with other resources and the like will be specifically described. The resource 121 (subject) "http: //.../ ex1" has a property (predicate) "rdf: type" with a resource 115 (object) "ex: genre name" and is called "Chinese". It has a property (predicate) called "ex: name" that has a literal 131 (object). That is, "http: //.../ ex1" represents the genre name "Chinese food".

The resource 122 (subject) "http: //.../ ex2" has the property (predicate) "rdf: type" with the resource 117 (object) "ex: restaurant" and "http: /". A property (predicate) called "ex: genre" with a resource 121 (object) called "/.../ ex1" and a property called "ex: name" with a literal 132 (object) called "Chinese Totsuka" ( Have a predicate). That is, "http: //.../ ex2" represents a Chinese restaurant named "Chinese Totsuka". The property (predicate) "ex: genre" is defined by the resource 114 "ex: genre" of the attribute information definition 110, and is shown in the resource group 120 in FIG. 2 in order to show this correspondence. A dotted line with an arrow is connected from the property (predicate) of "ex: genre" to the resource 114 of "ex: genre" of the attribute information definition 110.

The resource 123 (subject) "http: //.../ ex3" has the property (predicate) "rdf: type" with the resource 115 (object) "ex: genre name" and is called "Japanese food". It has a property (predicate) called "ex: name" that has a literal 133 (object). That is, "http: //.../ ex3" represents the genre name "Japanese food".

The resource 124 (subject) "http: //.../ ex4" has a property (predicate) "rdf: type" with a resource 115 (object) "ex: genre name" and "http: /". A property (predicate) called "ex: genre" with a resource 123 (object) "/.../ ex3" and a property (predicate) "ex: name" with a literal 134 (object) called "soba" have. That is, "http: //.../ ex4" represents the genre name "soba" in "Japanese food".

The resource 125 (subject) "http: //.../ ex5" has the property (predicate) "rdf: type" with the resource 115 (object) "ex: genre name" and "http: /". A property (predicate) called "ex: genre" with a resource 123 (object) called "/.../ ex3" and a property (predicate) called "ex: name" with a literal 135 (object) called "sushi". have. That is, "http: //.../ ex5" represents the genre name "sushi" in "Japanese food".

The resource 126 (subject) "http: //.../ ex6" has the property (predicate) "rdf: type" with the resource 117 (object) "ex: restaurant" and "http: /". A property (predicate) called "ex: genre" with a resource 124 (object) "/.../ ex4" and a property (predicate) "ex: name" with a literal 136 (object) called "Totsuka Soba" )have. That is, "http: //.../ ex6" represents a Japanese restaurant named "Totsuka Soba".

The concept of attribute information (that is, attribute information related to items that can be used in the dialogue scenario) handled in this embodiment has been described above. Next, a method of registering attribute information in the present embodiment will be described.

In the scenario creation support system 1 according to the present embodiment, the web service providing unit 13 of the scenario creation server 10 displays a web service screen (referred to as "attribute information management screen") for registering attribute information on the user terminal 20. Provided. Then, when the attribute information input by the user is transmitted to the attribute information management screen, the attribute information registration unit 14 of the scenario creation server 10 stores the input content (attribute information 100) in the attribute information storage unit 15. Register with.

3 and 4 are diagrams (No. 1 and No. 2) showing a screen configuration example of the attribute information management screen. The attribute information management screen 200 illustrated in FIGS. 3 and 4 is a web service screen on which attribute information can be input by user operation, and is based on the web service function by the web service providing unit 13 of the scenario creation server 10. It is displayed on the output unit 24 of the terminal 20. In this example, it is assumed that it is displayed on a window such as a web browser.

Further, as described with reference to FIG. 2, the attribute information is composed of the attribute information definition 110 and the resource group 120 that refers to the attribute information definition 110. Therefore, in this example, on the attribute information management screen 200, a tab for inputting the attribute information definition 110 (attribute information definition tab 210) and a tab for inputting the resource group 120 (resource group tab 220) are provided. It is assumed that the user performs an input operation on the display screen of each tab. However, the present embodiment is not limited to this display configuration, and for example, the display corresponding to each tab may be displayed on an independent and separate window, or at the same time on one window. It may be displayed.

FIG. 3 is a diagram showing a screen configuration example of the attribute information definition tab 210 in the attribute information management screen 200. As shown in FIG. 3, the attribute information definition input area 211 and the attribute information definition registration button 212 are arranged on the display screen of the attribute information definition tab 210.

The attribute information definition input area 211 is an area for inputting the attribute information definition 110. Although detailed description is omitted, FIG. 3 shows an input example of the attribute information definition corresponding to the attribute information definition 110 of FIG. In FIG. 3, as an example, RDF / RDFS is used as the data description format.

The attribute information definition registration button 212 is a button that is pressed after inputting the attribute information definition 110. When the attribute information definition registration button 212 is pressed, information such as the attribute information definition input to the attribute information definition input area 211 is transmitted to the scenario creation server 10 via the network 30. Then, in the scenario creation server 10, the attribute information registration unit 14 registers the attribute information definition 110 received from the user terminal 20 in the attribute information storage unit 15 based on the control of the control unit 11.

FIG. 4 is a diagram showing a screen configuration example of the resource group tab 220 in the attribute information management screen 200. As shown in FIG. 4, a resource group input area 221 and a resource group registration button 222 are arranged on the display screen of the resource group tab 220.

The resource group input area 221 is an area for inputting the resource group 120. Although detailed description is omitted, FIG. 4 shows an input example of the resource group (part) corresponding to the resource group 120 of FIG. In FIG. 4, as an example, RDF / RDFS is used as the data description format.

The resource group registration button 222 is a button that is pressed after inputting the resource group 120. When the resource group registration button 222 is pressed, information such as the resource group input to the resource group input area 221 is transmitted to the scenario creation server 10 via the network 30. Then, in the scenario creation server 10, the attribute information registration unit 14 registers the resource group received from the user terminal 20 in the attribute information storage unit 15 based on the control of the control unit 11.

As described above, by registering the attribute information 100 (attribute information definition 110 and resource group 120) related to the items that can be used in the scenario in the attribute information storage unit 15, the scenario creation server 10 can be used for the scenario described later. In the process related to the creation support, the presence or absence of inconsistent parts of the scenario can be verified by using the attribute information 100.

(3) Scenario creation support The scenario creation support method by the scenario creation support system 1 according to the present embodiment will be described.

FIG. 5 is a flow chart showing the flow of scenario creation support. Before the process shown in FIG. 5 is started, the attribute information 100 (attribute information definition 110 and resource group 120) related to the items that can be used in the scenario is registered in the attribute information storage unit 15. And.

First, in step S101, a scenario is created in the user terminal 20. More specifically, by providing the web service by the scenario creation server 10, a predetermined screen (scenario creation screen) used for creating a scenario is displayed on the output unit 24 of the user terminal 20, and the scenario creation screen is displayed. The scenario is created by the user performing a predetermined input operation for selecting and arranging the scenario parts. A specific example of the scenario creation screen will be described later with reference to FIG.

In the next step S102, the user terminal 20 transmits the scenario created on the scenario creation screen to the scenario creation server 10 via the network 30. The transmission in step S102 may be triggered by an operation using the user terminal 20 (for example, pressing a predetermined button, etc.), or may be periodically transmitted at a preset time interval or the like.

In the next step S103, the scenario creation server 10 (scenario verification unit 16) contradicts the scenario received from the user terminal 20 in step S102 by using the attribute information 100 registered in the attribute information storage unit 15. Verify the presence or absence of certain scenario parts (scenario part verification). Details of the scenario component verification will be described later with reference to FIG. 7.

In the next step S104, the scenario creation server 10 transmits the verification result in step S103 to the user terminal 20 via the network 30. At this time, the verification result may be transmitted only when a scenario component having a contradiction is found in step S103. In addition, information other than the inconsistent scenario parts may be transmitted together.

Then, in step S105, the user terminal 20 presents the scenario component on the scenario creation screen when there is a contradiction scenario component based on the verification result received from the scenario creation server 10 in step S104. When the inconsistent scenario parts are presented in this way, the user can create a consistent scenario by deleting the target scenario parts from the scenario.

FIG. 6 is a diagram showing a configuration example of the scenario creation screen. The scenario creation screen 300 illustrated in FIG. 6 is a web service screen on which a scenario can be created by user operation, and is an output unit of the user terminal 20 based on the web service function by the web service providing unit 13 of the scenario creation server 10. It is displayed on 24. In this example, it is assumed that it is displayed on a window such as a web browser.

As shown in FIG. 6, a scenario creation area 310 and a scenario component selection area 320 are arranged on the scenario creation screen 300.

The scenario creation area 310 is an area for creating a scenario, in other words, the created scenario (or the scenario being created) is displayed.

The scenario component selection area 320 is an area in which scenario components are arranged. The scenario component is a component of the scenario. For example, the scenario component 321 of "SELECTION" is a scenario component that means a branch of the scenario, and the scenario component 322 of "FLAG: xx (TRUE / FALSE)" is the scenario component of the scenario. It is a scenario component that means a branch destination. In the "xx" part of the scenario component 322, for example, "TRUE" meaning affirmative (YES) or "FALSE" meaning negative is entered. Further, the scenario parts that can be used in this embodiment are not limited to those shown in the legend in the figure.

In this example, the GUI (Graphic User Interface) is used to create the scenario, and the selected scenario parts are dragged and dropped into the scenario creation area 310 by dragging and dropping the scenario parts arranged in the scenario parts selection area 320 into the scenario creation area. It can be displayed on 310. Then, by connecting the scenario parts displayed in the scenario creation area 310 with arrows, the relationship between the scenario parts and the flow of the scenario can be described, and a scenario for dialogue can be created.

Specifically, the scenario parts illustrated in FIG. 6 are confirmed. In FIG. 6, in the scenario creation area 310, scenario parts 311 to 316 connected to each other by arrows are displayed.

First, in the scenario component 311, the scenario component of "SELECTION" is used to ask whether or not he likes Japanese food, and the dialogue content "Do you like Japanese food?" Is entered in the scenario component 321. At this time, since "Japanese food" in "Do you like Japanese food?" Is a phrase corresponding to the literal 133 (see FIG. 2) registered in the attribute information 100, it is stored in the attribute information storage unit 15. The resource 123 can be referred to by describing the URI (Uniform Resource Identifier) of the resource 123 that points to the literal 133 among the resource group 120. In FIG. 6, in order to explicitly indicate the reference destination, the URI of the target resource (in this case, “http: //.../ ex3”) is surrounded by the “$” mark.

Next, the scenario component 312 of "FLAG: FALSE" and the scenario component 313 of "FLAG: TRUE" are connected as the branch destination of the scenario component 311. The scenario component 312 of "FLAG: FALSE" is a branch destination when the answer "I do not like Japanese food (NO)" is obtained in the scenario component 311, and the scenario component 314 is connected. On the other hand, the scenario component 313 of "FLAG: TRUE" is a branch destination when the answer "I like Japanese food (YES)" is obtained in the scenario component 311, and the connection after that is omitted.

In the scenario part 314, the scenario part of "SELECTION" is used to ask whether or not you like Chinese food as the next question, and the dialogue content "Do you like Chinese food?" Is entered. Furthermore, since "Chinese food" in "Do you like Chinese food?" Is a phrase corresponding to the literal 131 registered in the attribute information 100, the URI is the same as in the case of "Japanese food" in the scenario component 311. By describing (details are omitted), the resource 121 (http: //.../ ex1) of the resource group 120 is referred to.

Next, the scenario component 315 of "FLAG: FALSE" is connected as the branch destination of the scenario component 314. Further, the scenario component 315 is connected to the scenario component 316 of "SELECTION" for asking whether or not he likes soba. Since it is the same as the scenario parts 311, 314, detailed explanation is omitted, but the dialogue content "Do you like soba?" Is entered in the scenario part 316, and "Do you like soba?" From "Soba", the resource 124 (http: //.../ ex4) of the resource group 120 is referred to.

In FIG. 6, an exclamation mark is displayed on the scenario component 316, but this is a scenario component having a contradiction in the verification of the presence or absence of the contradiction scenario component (scenario component verification). This is a presentation example. Here, detailed processing in scenario component verification will be described with reference to FIG. 7.

FIG. 7 is a flowchart showing an example of the processing procedure for scenario component verification. As described above in step S103 of FIG. 5, the scenario component verification shown in FIG. 7 is attribute information for the scenario created in the scenario creation area 310 of the scenario creation screen 300 (components are scenario components 311 to 316). The attribute information 100 registered in the storage unit 15 is used to verify the presence or absence of inconsistent scenario parts. The scenario component verification is executed by the scenario verification unit 16 of the scenario creation server 10 by using the program stored in the verification rule storage unit 17 and the rules of the rule engine that performs branch processing.

According to FIG. 7, first, the process proceeds to the scenario component to be verified (step S201). More specifically, at the time of the first verification, the process proceeds to the first scenario component (scenario component 311 in the case of the scenario of FIG. 6), and at the other verification, the next scenario connected to the previously verified scenario component. Proceed to the component (for example, after verifying the scenario component 311, the scenario component 312 or the scenario component 313).

Next, it is confirmed whether or not the scenario component (scenario component to be verified) advanced in step S201 is the scenario component of "SELECTION" (step S202). If it is a scenario component of "SELECTION" (YES in step S203), the process proceeds to step S204. On the other hand, if it is not a scenario component of "SELECTION" (NO in step S203), the process proceeds to step S208. Specifically, for example, when the verification target is the scenario component 311 and the scenario component is the “SELECTION”, the process proceeds to step S204.

In step S204, the resource group 120 registered in the attribute information storage unit 15 is referred to, and the resource that is the object of the referenced resource is acquired from the scenario component of the “SELECTION” to be verified. Specifically, for example, when the verification target is the scenario component 311, the referenced resource is the resource 123 "http: //.../ ex3", and the object that is the object is "ex". It is a resource 115 called ": genre name" (see FIG. 2).

Next, whether or not the resource acquired in step S204, that is, the resource that is the object of the resource referenced from the scenario component to be verified, is a resource stored in the "non-selected resource array". Is confirmed (step S205). If the resource is stored in the non-selected resource array (YES in step S206), the process proceeds to step S213. On the other hand, if the resource is not stored in the non-selected resource array (NO in step S206), the process proceeds to step S207.

Here, the "non-selected resource array" means that in the scenario component verification, items (resources) for which negative selection is made are accumulated while the scenario components constituting the dialogue scenario are sequentially verified along the flow of the scenario. More specifically, when a negative selection is made in an element selection type scenario component (for example, a scenario component of “SELECTION”), resources referred to by the scenario component are accumulated. The non-selected resource array is commonly used during scenario component verification for one scenario. When the verification target is the first scenario component 311, no resource is stored in the non-selected resource array, so the resource 115 acquired in step S204 is not a resource stored in the “non-selected resource array”. , Step S207 will proceed.

Then, in step S207, the resource referenced from the scenario component to be verified is stored in the "variable TMP". The "variable TMP" is a variable for temporarily holding a resource that may be stored in the non-selected resource array. Specifically, for example, when the verification target is the first scenario component 311, the resource referenced from the scenario component 311 is the resource 123 "http: //.../ ex3" as described in step S204. Yes, this resource 123 is stored in the variable TMP. Then, after the processing of step S207, the process returns to step S201, and the processing is repeated with the next scenario component as the verification target.

On the other hand, in step S208 proceeding to the case where the scenario component to be verified is not the scenario component of "SELECTION" (NO in step S203), the scenario component (scenario component to be verified) advanced in step S201 is "FLAG: xx". Check if it is a scenario part of. If it is a scenario component of "FLAG: xx" (YES in step S209), the process proceeds to step S210. On the other hand, if it is not the scenario component of "FLAG: xx" (NO in step S209), the process returns to step S201, and the process is repeated with the next scenario component as the verification target. Specifically, for example, when the verification target is the scenario component 312, since it is the scenario component of “FLAG: xx”, the process proceeds to step S210.

Note that FIG. 7 shows a process for discriminating "SELECTION" or "FLAG: xx" for the type of scenario component to be verified (steps S202 and S208), but these are examples of the process, and this implementation is performed. The scenario component verification in the form of is not limited to excluding processing for other types of scenario components. That is, the types of other types of scenario parts may be similarly determined, and processing may be performed according to the types.

In step S210, it is confirmed whether or not the value of the scenario component of “FLAG: xx” to be verified is “TRUE”. If the value of the scenario component is "TRUE" (YES in step S211), the process returns to step S201, and the process is repeated with the next scenario component as the verification target. On the other hand, if the value of the scenario component is not "TRUE", that is, "FALSE" (NO in step S211), the process proceeds to step S212. Specifically, for example, when the verification target is the scenario component 312, the value is “FALSE”, so the process proceeds to step S212.

Then, in step S212, the resources stored in the variable TMP are stored in the non-selected resource array. Specifically, for example, when the verification target is the scenario component 312, the resource 123 "http: //.../ ex3" is set in the variable TMP in step S207 during the processing for the previous scenario component 311 to be verified. Is stored, so this resource 123 (http: //.../ ex3) is added to the non-selected resource array. In order to avoid storing duplicate resources, it is preferable to clear the variable TMP after storing in the non-selected resource array. Then, after the end of step S212, the process returns to step S201, and the process is repeated with the next scenario component as the verification target.

As described above, in the scenario component verification shown in FIG. 7, the resource that is the object of the resource referenced from the scenario component to be verified is a resource stored in the non-selected resource array. Unless it is determined (NO in step S206), the processes of steps S201 to S212 are repeated for each scenario component 311 to 316 in the flow order of the scenarios created in the scenario creation area 310. Therefore, when step S206 is "NO" for all the scenario parts 311 to 316 constituting the scenario, it is determined that there is no contradiction in the scenario parts and there is no contradiction in the scenario. Although not shown in FIG. 7, at this time, the scenario component verification process ends.

On the other hand, if it is determined that the resource that is the object of the resource referenced from the scenario component to be verified is a resource stored in the non-selected resource array (YES in step S206), step S213. In, it is determined that the scenario component to be verified at present is a inconsistent scenario component, and the scenario component verification is terminated (stopped).

The above is the processing procedure for the scenario component verification shown in FIG. Hereinafter, specific processing results when such scenario component verification is applied to the scenario created in the scenario creation area 310 in FIG. 6 will be described. In the above description with respect to FIG. 7, the specific processing when the scenario parts 311, 312 are targeted for verification has already been described. Further, the description of the scenario component (for example, scenario component 313) of "FLAG: xx" whose value is "TRUE" will be omitted.

First, as mentioned above, the scenario part 311 of "SELECTION" that says "Do you like Japanese food $ http: //.../ ex3 $?" And the scenario part 312 of "FLAG: xx" that says "No". In the scenario component verification to be verified, no inconsistent scenario component is found, and the resource 123 (http: //.../ ex3) is stored in the non-selected resource array.

Then, the scenario component 314 of "SELECTION", which is "Do you like Chinese $ http: //.../ ex1 $?", Is selected as the next verification target (step S201). Since the scenario component 314 is a scenario component of "SELECTION", the process proceeds to step S204.

The resource referenced from the scenario component 314 is the resource 121 "http: //.../ ex1", and the resource whose object is the resource 115 is the resource "ex: genre name". Therefore, in step S204, the resource 115 (ex: genre name) is acquired.

In the next step S205, since the resource 115 (ex: genre name) is not stored in the non-selected resource array, it becomes NO in step S206, and in step S207, the resource referenced from the scenario component 314 to be verified, that is, Store the resource 121 (http: //.../ ex1) in the variable TMP. This completes the scenario component verification for the scenario component 314.

For the next verification target, the scenario component 315 of "FLAG: xx" called "No" is selected (step S201). Since the scenario component 315 is not a scenario component of "SELECTION" but a scenario component of "FLAG: xx", the process proceeds to step S210 through NO in step S203, YES in step S208, and YES in step S209.

Further, in step S210, since the value of the scenario component 315 to be verified is not "TRUE", the process proceeds to step S212 through NO in step S211. Then, in step S212, the resource 121 (http: //.../ ex1) stored in the variable TMP in the scenario component verification for the scenario component 314 is additionally stored in the non-selected resource array, and the scenario component verification for the scenario component 315 is performed. Is finished.

In this way, at the time when the scenario component verification for the scenario components 311 to 315 is completed, no inconsistent scenario component is found, and the resource 123 (http: //.../ ex3) is found in the non-selected resource array. And resource 121 (http: //.../ ex1) are stored.

Then, the scenario component 316 of "SELECTION", which is "Do you like soba $ http: //.../ ex4 $?", Is selected as the next verification target (step S201). Since the scenario component 316 is a scenario component of "SELECTION", the process proceeds to step S204.

The resource referred to from the scenario component 316 is the resource 124 called "http: //.../ ex4", and the resource whose object is "ex: genre name" is the resource 115 and "http:". Since it is the resource 123 "//.../ ex3", in step S204, the resource 115 (ex: genre name) and the resource 123 (http: //.../ ex3) are acquired.

In the next step S205, it is confirmed whether or not the resource 115 or the resource 123, which is the object of the resource referenced from the scenario component 316 to be verified, is a resource stored in the non-selected resource array. At this time, since the resource 123 (http: //.../ ex3) and the resource 121 (http: //.../ ex1) are stored in the non-selected resource array, the resource 123 (http: // ... / ex1) is stored. ... / ex3) corresponds to this, and the process proceeds to step S213 through YES in step S206.

By proceeding to step S213, the scenario part 316 of "SELECTION", which is the current verification target "Do you like soba $ http: //.../ ex4 $?", Is considered to be a contradictory scenario part. Judgment is made, and this is the verification result of the scenario component verification.

Then, as described in steps S104 and S105 of FIG. 5, the verification result of the scenario component verification is transmitted from the scenario creation server 10 to the user terminal 20 via the network 30, and is inconsistent on the scenario creation screen 300 of the user terminal 20. A scenario component 316 is presented. In the case of FIG. 6, an exclamation mark is displayed on the scenario component 316 as an example of the method of presenting that the scenario component has a contradiction, but the presentation method is not limited to such a display method.

If no inconsistent scenario parts are found for all the scenario parts 311 to 316 that make up the scenario created in the scenario creation area 310, the scenario creation screen 300 indicates that the scenarios are not inconsistent. You may try to do it.

As described above, according to the scenario creation support system 1 according to the present embodiment, attribute information regarding items that can be used in the dialogue scenario is registered, and based on the registered attribute information, there is a contradiction in the scenario. It is possible to present the part (scenario part) to the user, and it is possible to support the creation of a scenario (in other words, a consistent scenario) in which unnecessary questions are not mixed. That is, in scenario creation, the user can easily create a scenario (consistent scenario) in which unnecessary questions are not mixed by removing the inconsistent scenario presented by the scenario creation support system 1 according to the present embodiment. Can be created in.

1 Scenario creation support system 10 Scenario creation server 11 Control unit 12 Network interface unit 13 Web service provision unit 14 Attribute information registration unit 15 Attribute information storage unit 16 Scenario verification unit 17 Verification rule storage unit 18 BUS (bus)
20 User terminal 21 Control unit 22 Network interface unit 23 Input unit 24 Output unit 25 BUS (bus)
30 Network 100 Attribute information 100a, 100b Range 110 Attribute information definition 111, 112 Class 113-117 Resource 120 Resource group 121-126 Resource 131-136 Literal 200 Attribute information management screen 210 Attribute information definition tab 211 Attribute information definition input area 212 Attribute Information definition registration button 220 Resource group tab 221 Resource group input area 222 Resource group registration button 300 Scenario creation screen 310 Scenario creation area 311 to 316,321,322 Scenario parts 320 Scenario parts selection area

Claims (8)

It is a scenario creation support system that verifies an interactive scenario composed by connecting multiple scenario parts.
In response to user input, as attribute information related to the literal that can be used in the scenario component, the attribute information definition that defines the reference relationship between the plurality of first resources indicating the attribute and the attribute, and the literal corresponding to itself are provided. An attribute information registration unit that has a resource group of a second resource that has and refers to any one of the first resources defined in the attribute information definition, and an attribute information registration unit that registers the resource group in the storage device.
For the scenario created by concatenating the plurality of scenario parts using the literal, the referenced resource referred to by each scenario part is used for the scenario part in the order of concatenation of the scenario parts. A scenario verification unit that determines scenario parts that are inconsistent with the background of the dialogue of the scenario by specifying based on the registered contents in the attribute information of the second resource corresponding to the above and comparing the specified referenced resources. When,
Equipped with
The plurality of scenario parts constituting the scenario include a first scenario part indicating a question for which selection is requested, and a second scenario part indicating a selection result for the question.
The scenario verification unit
While verifying the plurality of scenario parts constituting the scenario in the order of connection,
The referenced resource specified for the first scenario component to which the second scenario component indicating a negative selection result is concatenated is stored in the non-selected resource array.
When the referenced resource specified for another first scenario component connected to the rear side of the second scenario component is stored in the non-selected resource array, the other first scenario component is stored. Judging that the scenario part is the contradictory scenario part
A scenario creation support system characterized by this. The first aspect of the present invention is characterized in that, in the scenario, the literal used in the scenario component is described by the URI (Uniform Resource Identifier) of the second resource corresponding to the literal in the resource group. Scenario creation support system. An attribute information management screen for inputting the registered contents of the attribute information and a scenario creation screen for creating the scenario by combining a plurality of scenario parts using the literals of the resources registered in the attribute information. The scenario creation support system according to claim 1, further comprising a web service providing unit that is provided in a form that can be operated by a user. The scenario creation support system according to claim 3 , wherein the web service providing unit displays a determination result of the contradictory scenario parts by the scenario verification unit on the scenario creation screen. It is a scenario creation support method by a scenario creation support system that verifies an interactive scenario composed by connecting multiple scenario parts.
In response to user input, the scenario creation support system defines attribute information that defines a plurality of first resources indicating attributes and reference relationships between the attributes as attribute information related to the literal that can be used in the scenario component. An attribute information registration step for registering a resource group of a second resource having the literal corresponding to itself and referring to any of the first resources defined in the attribute information definition in a storage device, and
For the scenario created by the scenario creation support system by concatenating the plurality of scenario parts using the literal, the reference resource referred to by each scenario part is referred to in the scenario in the order of concatenation of the scenario parts. The second resource corresponding to the literal used for the component is specified based on the registered contents in the attribute information registered in the attribute information registration step, and the specified referenced resource is compared. A scenario verification step to determine scenario parts that conflict with the background of the scenario dialogue, and
Equipped with
The plurality of scenario parts constituting the scenario include a first scenario part indicating a question for which selection is requested, and a second scenario part indicating a selection result for the question.
In the scenario verification step,
While the scenario creation support system verifies the plurality of scenario parts constituting the scenario in the order of connection,
The referenced resource specified for the first scenario component to which the second scenario component indicating a negative selection result is concatenated is stored in the non-selected resource array.
When the referenced resource specified for another first scenario component connected to the rear side of the second scenario component is stored in the non-selected resource array, the other first scenario component is stored. Judging that the scenario part is the contradictory scenario part
A scenario creation support method characterized by this. The fifth aspect of the present invention is characterized in that, in the scenario, the literal used in the scenario component is described by the URI (Uniform Resource Identifier) of the second resource corresponding to the literal in the resource group. Scenario creation support method. Prior to the attribute information registration step, the scenario creation support system provides a first display step in which the attribute information management screen for inputting the registered contents of the attribute information is provided in a form that can be operated by the user.
After the attribute information registration step, the scenario creation support system can operate a scenario creation screen for creating the scenario by combining a plurality of scenario parts using the literals of the resources registered in the attribute information. The scenario creation support method according to claim 5 , further comprising a second display step provided in various forms. The scenario creation support according to claim 7 , wherein the scenario creation support system further includes a third display step for displaying the determination result of the contradictory scenario component in the scenario verification step on the scenario creation screen. Method.

Images