JP2006244126A - Interactive cooperative work support system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently and accurately support cooperative work by a plurality of users. <P>SOLUTION: An interactive cooperative work support system for supporting cooperative work by a plurality of users comprises an interaction execution part 30 for inputting and outputting voice interaction information among the users A to D, etc., a plurality of interaction control parts 11A to 11D, etc. for managing interaction models depending on users' roles, and controlling state transitions of the associated interaction models according to the interaction information inputs from the connected users to generate new interaction scenarios outputted to the connected users, and a synchronous control part 12 for managing common conditions for the synchronous state transition of necessary interaction control parts according to the interaction information inputs from a plurality of the users A to D, etc. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to an interactive collaborative work support system, and more particularly to an interactive collaborative work support system that supports collaborative work in which a plurality of users perform a series of work items in concert. In work that is performed under conditions where the action and confirmation are separated, such as construction of water supply valves and faucets and maintenance of production facilities in the factory, it is necessary for multiple workers to perform the tasks in a coordinated manner. is there.

  Conventionally, when a plurality of workers work in close proximity to each other, a work support information request voice pattern of each worker is registered in advance, and a work support information request voice input from a worker is received. There is known a work support system that identifies and selects only registered speech, reads out corresponding work support information, and displays it to the worker (Patent Document 1). Thereby, each worker can request the work support information by voice without being disturbed by the voice of the next worker while continuing the original work.

Also, in the past, work processes were not considered as a whole flow, but independently, so that work instructions were issued for work that could be performed regardless of the order in which work proceeded and which part of work preceded. A collaborative work support system that can be regarded as a collection of work and can issue work instructions based on the execution conditions of each work is known (Patent Document 2).
JP-A-11-327587 (summary, figure) JP 10-154177 (paragraph "0011")

  However, it is assumed that all the work in the above prior art proceeds independently for each worker, and there is no viewpoint of performing the work among a plurality of workers in cooperation (synchronization). For this reason, in the prior art, it has not been possible to support collaborative work that is performed under a certain degree of synchronization under a condition where the action and confirmation points are separated.

  The present invention has been made in view of the above-described problems of the prior art, and an object of the present invention is to provide an interactive collaborative work support system that can efficiently and accurately support a work performed in cooperation by a plurality of users. It is in.

  The above problem is solved by the configuration of FIG. In other words, the interactive collaborative work support system of the present invention (1) is an interactive collaborative work support system that supports collaborative work by a plurality of users. To manage the dialog execution unit 30 that performs output and the dialog model according to the role of each user, and to control the state transition of its own dialog model based on the dialog information input from the connected user and output it to the connected user A plurality of dialogue control units 11A to 11D that generate a new dialogue scenario and a common dialogue control unit that performs a state transition synchronously based on dialogue information input from the plurality of users A to D, etc. And a synchronization control unit 12 for managing conditions.

In the present invention (1), based on dialogue information input from a plurality of users A to D, etc., by providing a synchronization control unit 12 that manages a common condition for a required dialogue control unit to make a state transition in synchronization, For example, remote operation actions and operation check actions can be efficiently managed in pairs, such as “brake operation” and “brake operation check” in bus vehicle inspection work. Further, not only dialogue input from the worker but also dialogue output to the worker is performed by voice, so that each worker can perform his / her own work hands-free and eyes-free. Furthermore, it is not a method in which workers directly communicate with each other, but the configuration in which cooperation is established through the task control unit 10 makes it possible to improve the efficiency of work, and to obtain safe operation and work history easily.

  In the present invention (2), in the present invention (1), the synchronization control unit 12 causes the required dialog control unit to transition to the next state based on the dialog information input indicating the completion of the work from the required user. It is. Therefore, work synchronization (cooperation) among a plurality of users can be obtained efficiently and reliably.

  In the present invention (3), in the above-mentioned present invention (1), the synchronization control unit 12 shifts the required dialogue control unit to the suspended state based on the dialogue information input indicating that the work is suspended by any user. is there. Therefore, even if an inconvenience (delay or the like) occurs in the work of a certain user, it is possible to efficiently wait for the work of other users all at once.

  According to the present invention (4), in the above-mentioned present invention (1), the synchronization control unit 12 detects a failure in a call between any user and the dialog execution unit 30, and thereby detects a required dialog control unit. Transition to a suspended state due to a call failure. Therefore, even when a line failure occurs, it can be automatically dealt with in the same way as an interruption instruction from the user.

  In the present invention (5), in the above-mentioned present invention (1), the synchronization control unit 12 changes the current state in the required dialogue control unit based on the dialogue information input for returning the work by any user to the previous stage. The state is transitioned to. Therefore, even if a certain user's work is redone, it is possible to efficiently and efficiently return the work of other users to the previous work.

  In the present invention (6), in the above-mentioned present inventions (1) to (5), the dialog control unit 11 has the current state managed by itself when the common condition in the synchronization control unit 12 is satisfied, Based on the dialogue information input by the user, the utterance to be output next by the user and the information to be collected from the user are determined. Therefore, the dialogue (scenario) for each user can be smoothly operated.

  In the present invention (7), in the present inventions (1) to (6), a dialogue model for managing the occurrence of a predetermined event is managed, and the dialogue processing in a plurality of dialogue control units is interrupted to create another dialogue. It includes a scenario insertion unit 11S that inserts a scenario and executes dialogues with a plurality of users. Therefore, even if an event (abnormality, etc.) occurs during the work or it is necessary to perform an unsteady operation, various predetermined dialogue scenarios corresponding to these events are forcibly interrupted in the middle. Can deal effectively with any situation.

  In the present invention (8), in the present invention (1), the dialogue control unit 11 manages the dialogue model corresponding to the skill based on the personal information reflecting the skill of the connected user. Therefore, it is possible to easily share roles in consideration of user skills.

  As described above, according to the present invention, it is possible to efficiently support collaborative work by a plurality of physically separated users. Therefore, this embodiment greatly contributes to the safety implementation and efficiency improvement of this kind of collaborative work.

DESCRIPTION OF EXEMPLARY EMBODIMENTS Hereinafter, preferred embodiments of the invention will be described in detail with reference to the accompanying drawings. Note that the same reference numerals denote the same or corresponding parts throughout the drawings.

  FIG. 1 is a diagram showing a configuration of an interactive cooperative work support system according to an embodiment. This support system is roughly divided into a web server (task processing unit) 10 that synchronously controls execution of cooperative work by a plurality of users, A dialogue server (dialog execution unit) 30 that executes voice dialogue with a plurality of users (clients).

  In the Web server 10, 11A to 11D are generated for each user, a dialog control object (corresponding to the dialog control unit of the present invention) 12 for controlling the execution (progress) of the dialog with each connected user A to D, 12 A synchronization control object (corresponding to the synchronization control unit of the present invention) that controls the synchronization of the dialog control among the dialog control objects 11A to 11D, 13 is a servlet that accepts an HTTP request from the dialog server 30, and 14 is a VoiceXML document (one example) JSP {Java (registered trademark) Server Pages} which is a template of a list written in a dialog description language), 20 is a VoiceXML database storing information necessary for generating a dialog scenario, and 15 is stored in the VoiceXML database 20. Database (DB) cooperation module for connection, 100 is a Web server An IP network which connects the interaction server 30 and server 10.

  In the dialogue server 20, 31 is a VoiceXML interpreter that interprets and executes a voice XML dialogue scenario, 32 is a speech recognition unit (ASR) that recognizes speech from the user, and 33 is a speech synthesis unit (TTS) that synthesizes speech to the user. , 34 is a telephone board interface (I / F) for accommodating telephone terminals, 200 is a public switched telephone network (PSTN), and 50 is a telephone terminal (cellular phone, PHS, etc.) used by a user. Preferably, by using the hands-free type telephone terminal 50, each of the users A to D can concentrate exclusively on work with hands-free and eyes-free.

  Next, the one-to-one dialog control between the dialog control object 11 and the user will be described. The dialog control with the user basically performs the necessary work for the utterance (work instruction) from the dialog control object 11, responds the work result, and based on the response content. The state in the dialog control object 11 is changed, and the process proceeds in a form in which a new utterance (work instruction) is generated.

  For example, when the user A accesses a specific telephone number with the mobile phone 50 </ b> A, the call arrives at the telephone board I / F 34 of the dialog server 30. The dialog server 30 generates a VoiceXML interpreter 31A for the user A, and the interpreter 31A analyzes the user A's utterance content and sends an HTTP (GET / POST) corresponding to the utterance content to the Web server 10. Send a request.

  In the Web server 10, the dialog control object 11A for the user A is generated, and the servlet 13 receives the parameter information obtained by the dialog with the user A from the HTTP request and passes it to the dialog control object 11A.

  The dialog control object 11A changes its own state based on the acquired parameter information, and also accesses the VoiceXML database 20 via the database linkage module 15 to provide a dialog scenario (prompt, required for dialog control with the user A). Grammar etc.). Further, the selected prompt or grammar is embedded in the corresponding template by the JSP 14 to generate a VoiceXML document (ie, a dialogue scenario) and return it to the VoiceXML interpreter 11A. The VoiceXML document is interpreted by the VoiceXML interpreter 11A, further synthesized into speech by the speech synthesizer 33, and output to the user A.

  The user A performs necessary work according to the output sound from the system and inputs a new sound. The dialog control object 11A transitions to a new state based on the response content and generates a new utterance (work instruction). By repeating such interactive control, the work in charge of the user A is sequentially performed. The same applies to the other users B to D.

  Next, the synchronous control of the cooperative work by the users A to D will be described. By sharing one synchronization control object 12 among the dialog control objects 11A to 11D, synchronization control of cooperative work among the users A to D is realized. The synchronization control object 12 manages a synchronization flag for each of the dialog control objects 11A to 11D, and each synchronization flag is reset by a new work instruction to the users A to D. Each is set when there is a notification of completion of work.

  Then, when all the synchronization flags are set, the state transitions in the dialog control objects 11A to 11D are energized (enabled). This synchronization flag is set by a work completion notification from the user, but is not set by other notifications (such as a work interruption from the user, a notification of an instruction to return to the previous work, etc.). In this way, the synchronous control of the cooperative work by the users A to D is efficiently performed.

  The transition condition is that all the synchronization flags are set, but the present invention is not limited to this. Actually, only a work completion notification from a required user is required according to various types of work items (work type, number of persons, operation / confirmation role assignment, etc.). That is, this is a condition for state transition. In the present invention, in each scene, a user who satisfies such a requirement is represented by the word “required user”, and a predetermined dialog control unit that is to be changed in state upon satisfaction of the requirement is designated as “required user”. It is expressed by the word “dialogue control unit”. Further, although not shown in the drawing, which user (or dialogue control unit 11) corresponds to the required user (or dialogue control unit 11) is determined in advance according to each type of work item and the synchronization control unit 12 and / or each user. It is managed within the corresponding interaction model.

  FIG. 2 is a sequence diagram of the interactive cooperative work support process according to the embodiment, and shows a part of the cooperative work by the users A and B. First, the dialog control object 11A is generated by the connection of the user A. Thereafter, when user A inputs personal information (user name, ID information, etc.) in response to a request from the system, based on the task data stored in database 20 and user A's personal information, user A's A dialogue model A corresponding to the role is generated, and accordingly, the user A is in a state where the first dialogue scenario A1 is requested. Upon receiving this, the dialogue model 11A registers the state of the user A (that is, the dialogue model A) in the synchronization control object 12, and waits for synchronization by the synchronization control object 12 (in this example, waits for the connection of the user B). It becomes a state.

  Next, the dialog control object 11B is generated by the connection of the user B. Thereafter, when the dialog model B generated in the same manner as described above registers the state of the user B (that is, the dialog model B) in the synchronization control object 12, the synchronization in the waiting state is obtained in the synchronization control object 12. It becomes a state. As described above, the synchronization control object 12 always manages the states of the dialogue models A and B, and determines whether or not it is necessary to wait for the synchronization inquiry from each dialogue model A and B. And can respond to the inquiry. FIG. 2 shows that user A completes the dialog first, but cannot proceed to the next dialog scenario until user B completes the dialog.

In the dialog model A, when the synchronization state is obtained, the state to be changed next is determined based on the current state managed by the user and the parameter information input by the user. Specifically, the database 20 is accessed, the system-side utterance scenario to be output next is selected, the state associated therewith, and the information to be collected from the user A are determined. Further, these utterances, states, and information to be collected are embedded in a template (JSP) of the VoiceXML document, and are returned to the VoiceXML interpreter 31A as a result of the HTTP request.

  The user A receives the dialogue scenario A1 (task or the like) from the system, and executes the operation A1 and responds with the result by voice. In this response, not only the completion of the work but also an instruction to interrupt the work or return the work to the previous work may be performed depending on the situation of the work. These responses become requests for the next dialogue scenario A2 for the dialogue model A. In the dialogue model A that receives this response, the next state is managed based on the current state managed by the user and the response information input by the user. Determine the state to transition to. The same applies to user B who repeats the same processing until all tasks are completed.

  FIG. 3 is a diagram for explaining the flow of the synchronization control process according to the embodiment. FIG. 3A shows a work completion synchronization flag managed by the synchronization control object 12. The synchronization control object 12 manages a work completion synchronization flag provided for each user A to D for each work item. On the other hand, each of the dialog control objects 11A to 11D notifies the synchronization control object 12 of the input of the completion of the work from the user in each work item (or the work suspension or return to the previous work). The synchronization control object 12 sets a corresponding work completion synchronization flag when notification of work completion is given from the dialog control objects 11A to 11D. However, other instruction inputs (work suspension instruction, work to previous work) are set. The corresponding synchronization flag is not set in the case of an instruction to return. Therefore, the work completion synchronization state is achieved only when all work is completed.

  FIG. 3A shows the state of the work completion synchronization flag when the users A to D are performing the work item n, and the work completion from the users A, C, and D has already been notified. In this state, the user B is waiting for a voice input for completing the work. Preferably, at this time, the users A, C, and D are notified of a voice message (ex “Please wait for a while”) indicating that they are in a standby state. Then, when the completion of the work of all the users A to D is notified, determination of the state to be transitioned next in each of the dialog control objects 11A to 11D is activated.

  Although not shown in the drawing, in the same manner as the work completion synchronization flag, a work interruption instruction flag and an instruction flag for returning the work to the front are provided in correspondence to each of the dialog control objects 11A to 11D. Yes. As for the work interruption instruction flag, the synchronization determination of the work interruption of the entire user becomes valid at the time when any of the flags is first set, but the flag is reset by the user who issued the interruption instruction, thereby The synchronous determination of the interruption of work is canceled invalid.

  However, if the work interruption instruction flag by another user has been set before the first interruption instruction flag is reset, the entire user's operation will be stopped even after the first interruption instruction flag is reset. The work interruption synchronization judgment remains valid. Accordingly, work interruption instructions from a plurality of users are accepted at a time and are processed appropriately. As for the instruction to return the work to the front, a plurality of users are accepted in the same manner as described above, but when the work of the entire user is returned to the front by any one of the user's instructions, an instruction flag to return all the work Is reset once.

FIG. 3B shows a partial flow of the synchronous control process executed by the dialog control object 11. The processing item n is input to this process when the execution starts. In step S11, the synchronization flag of work completion of the synchronization control object 12 is checked. In step S12, it is determined whether or not all are completed. If all are completed, the work item to be executed is updated to (n + 1) in step S13, and this process is exited.

  If all the determinations in step S12 are not complete, it is determined in step S14 whether or not the cause is due to any user interruption instruction. In the case of a user interruption instruction, it is further determined in step S18 whether or not the user (the user to whom the dialogue control object 11 is connected) is an interruption instruction. (Ex "Work has been interrupted. Please say resume to resume work"). If the user is not the person himself / herself, in step S20, the user connected to the user is informed that the operation has been interrupted by another person (ex “The operation has been interrupted by the operation of Suzuki. Please wait for a while until the operation is resumed.” ). As described above, when any user instructs to suspend work, even if there is a user who has already completed the work, the work of all the users is suspended.

  In step S21, it is determined whether or not the interruption is resumed (all interruption instruction flags are released). If not, the process returns to step S18. In the case of resuming the interruption, after notifying that the work has been resumed (ex “resuming the suspended work is resumed”), the process returns to step S11 to continue waiting for the work item n to be completed. When the interrupted work is resumed, even if there is a user who has already completed the work, the work of all the users is started again from the beginning of the work item n.

  If it is determined in step S14 that the operation is not interrupted, it is further determined in step S15 whether an instruction (back instruction) for returning the current operation by any user to the previous operation is valid. If the back instruction is invalid, the work for work item n is still in progress, and the process returns to step S11. If the back instruction is valid, a notification is sent to the user to which he / she is connected in step S16 that the work is to be returned to the previous one (ex: “The operation will be returned to the previous work by Suzuki”). In S17, the own work item is updated to (n-1), and this process is exited. If any user instructs to return to the previous work, all users will return to the previous work even if there are users who have completed the work.

  Although not shown in the drawing, if a call connection between any user and the dialogue server 30 is disconnected due to a line failure or the like before completing all the work items, a kind of interruption occurs. Since it is different from the interruption instruction by the user himself, some means is required. In this case, for example, when a failure of a certain line is detected by the telephone board I / F 34, the voice XML interpreter 31 corresponding to the connected user connects the line to the dialog control object 11 corresponding to the connected user. It is possible to instruct interruption due to a failure and thereby automatically suspend the work of all other users. Eventually, when the telephone board I / F 34 detects the return of the line failure, an instruction for canceling the suspension is given through the same route as described above, whereby all users' work can be resumed.

  FIG. 4 is a diagram showing an example of dialogue according to the embodiment, and shows a case in which the users A and B perform cooperative work for water supply maintenance in time series. First, the user A registers with the system, and in this example, the connection waits for another user B necessary for cooperative work. Eventually, when the user B registers in the system, the synchronization of the waiting is obtained, thereby notifying the users A and B of the contents and location of the work, and starting a predetermined cooperative work.

FIG. 5 is a diagram for explaining the stored contents of the VoiceXML database 20 according to the embodiment, and specifically shows a case where the content is applied to a foot brake inspection work of a bus vehicle. The VoiceXML database 20 holds the state of the dialog control object, the system-side utterance (prompt) in the state, and information (Answer) to be collected from the user in the state for each state. Thus, a certain state is associated with information to be collected from the user in that state and a prompt to be output for that purpose.

  For example, the prompt for state "Login" is "Bus vehicle inspection system" and there is no answer to request. The prompt of the state “AskSagyoType” is “Do you do personal work or do you work together?” And the requested answer is “Personal work or group work”. Other states can be understood similarly.

Although not shown, the JSP (template) for generating VoiceXML in each state has the following types:
“Annouce” information presentation “Ask” question “Disconnect” dialog is terminated Notification of “Waiting” waiting
Notification of returning to the previous work
“Suspended” Notification of suspension
Request for "AskForResume" resume
"Resumed" Notification of resuming
"Reconnect" Notify that there is incomplete work
There is an “Error” error notification.

  6 and 7 are diagrams (1) and (2) for explaining a state transition pattern according to the embodiment. Refer to the explanation of FIG. 8 for the system operation of each block (state). FIG. 6 shows a case where each user inputs a work completion response (work pattern 1). Each user A to D voice-inputs that the work has been completed (operation completion, operation check, etc.) if there is no problem in response to the work instruction from the system, and the completion response of the required number of users is prepared. Now, go to the next work item. In this case, if any problem is found during the work, each user inputs a work interruption instruction by voice, and after solving the problem, inputs a work resumption instruction by voice. Each user can input an instruction to return to the previous work by voice when it becomes necessary to perform the previous work again. Also, the line failure for each line can be handled in the same manner as described above.

  FIG. 7 shows a case (work pattern 2) where only a representative (team leader) can input a work completion response. After confirming that the required user has completed the work offline (on-site), the team leader representatively inputs the completion of the work by voice. Preferably, work instructions from the system are repeatedly announced to each user other than the team leader until the team leader makes a voice input. Similarly, when returning to the previous work or suspending the work, the team leader represents the voice by voice on behalf of the team.

  Note that the Web server 10 considers personal information (such as holding the chief qualification of the work) of the user's skill and experience at the time of registration of each user, so that when the interaction model 11 is generated, the Web server 10 It is possible to automatically grant management authority like the team leader.

  FIG. 8 is a diagram for explaining the system operation in each state of FIGS. Each of the users A, C, and D in FIG. 6 needs to input the confirmation (Kakunin) 2 for the operation (Sousa) 2 of the user B, but each of the users A, C, and D in FIG. For the operation (Soisa) 2 of B, an announcement confirmation (AnounceKakunin) 2 without user input is performed. In this case, if necessary, the team leader (not shown) performs user input for confirmation (Kakunin) 2.

  FIG. 9 is a diagram showing the configuration of an interactive collaborative work support system according to another embodiment. In accordance with various events (such as unforeseen events) that occur during the operation of the system, an interactive scenario that is currently in progress is automatically performed. It shows a case where it is possible to forcibly insert another interactive scenario in place of interruption. In the figure, 11S temporarily interrupts the progress of the dialog scenario in the dialog control objects 11A to 11D when some event is detected during the system operation, and interrupts the task processing so far to perform a predetermined dialog. Scenario insertion units 31a to 31d for actively inserting scenarios are provided as extended functions of the dialog control objects 11A to 11D, receive an insertion scenario from the scenario insertion unit 11S, and communicate with the workers A to D. It is a scenario insertion corresponding part that executes a dialogue between them.

  Examples of the event include detection of an abnormality regarding the inspection target (may be an abnormality report on the inspection target by the user), detection of a line failure, detection of a failure related to the system, and the like. When a failure occurs on a PSTN line that is being used by a certain user, an interruption instruction may be sent from the line corresponding unit to the corresponding dialog control object 11 as described above. By notifying the section 11S, all work is temporarily suspended or stopped, and another normal PSTN line is used, or the number of workers is reorganized to continue the work from the middle, or separately It becomes possible to newly resume the work. Since a line failure or the like may not be recovered for a while even if the conversation is temporarily interrupted on the spot, it is efficient to deal with another conversation scenario according to the present invention.

  It should be noted that by providing the scenario insertion corresponding units 31a to 31d in each of the dialog control objects 11A to 11D, the voice XML document push function is used, so that one or two or more users can be used only once. You can easily insert scenarios (dialogues). For example, in this system, when the completion input of all workers is not obtained, each XML object is notified by the dialog control object 11 to notify each worker that the system is in a standby state (ex “wait for a while”. If each VoiceXML interpreter outputs it as a voice, an HTTP request indicating whether there is a state transition is sent from each interpreter to each dialog control object 11 again. Therefore, the actual timing at which the transition to the next state can be made when the condition at a certain point is satisfied is the voice prompt for the waiting worker. After waiting for a while, please use this scenario insertion function. For example, even when the voice prompt “Please wait for a while” is being reproduced, the reproduction can be easily interrupted and immediately shifted to the next state.

  Alternatively, when an operation such as “work interruption” or “return work” is performed by any user, the other worker is executing the original work scenario, and the work result is input by voice. However, if this scenario insertion function is used, all workers can be quickly notified that operations such as “work suspension” and “return work” have been performed. Is possible.

  Reference numeral 60 denotes a maintenance terminal for a maintenance person or the like to monitor the operation status of the system, and the maintenance person may insert a desired dialogue scenario from the maintenance terminal 60 to each user via the scenario insertion unit 11S. In this way, it is possible to flexibly cope with unexpected (unexpected) event occurrence.

FIG. 10 shows an example of dialogue according to another embodiment. In the case where an abnormality is discovered during work, a case in which a detailed report of the abnormality is obtained by quickly interrupting the dialogue model of the user who has detected the abnormality is shown. Shown in time series. Here, the users A and B share the operation of the valve and the water leak check of the pipe. When the user A opens the valve and the user B finds a water leak abnormality, the user A closes the valve by the notification. After that, the scenario insertion unit 11S inserts a new dialogue scenario, so that the user B reports the detailed examination status according to the request from the scenario insertion unit 11S. According to the present embodiment, when an emergency event occurs, or when an unusual dialogue process is necessary, any other user in any dialogue state can immediately interrupt the process. Is possible.

  In each of the above embodiments, the user uses the mobile phone 50. However, the present invention is not limited to this. In addition, this system can also be configured using a PHS, IP phone, or analog landline phone. In addition, a pre-recorded voice may be used instead of the synthesized voice.

  Moreover, although several embodiment suitable for the said invention was described, it cannot be overemphasized that the structure of each part, control, a process, and these combination can be variously changed within the range which does not deviate from this invention. .

It is a figure which shows the structure of the interactive collaborative work assistance system by embodiment. It is a sequence diagram of interactive cooperative work support processing according to an embodiment. It is a figure explaining the flow of the synchronous control processing by embodiment. It is a figure explaining the example of a dialogue by an embodiment. It is a figure explaining the memory content of the VoiceXML database by embodiment. It is a figure (1) explaining the state transition pattern by embodiment. It is a figure (2) explaining the state transition pattern by embodiment. It is a figure explaining operation | movement of the system in each STATE. It is a figure which shows the structure of the interactive collaborative work assistance system by other embodiment. It is a figure explaining the example of a dialogue by other embodiments.

Explanation of symbols

10 Web server (task processing unit)
11 Dialog control object 12 Synchronization control object 13 Servlet 14 JSP
15 Database (DB) linkage module 20 VoiceXML database 30 Dialog server (dialog execution unit)
31 VoiceXML interpreter 32 Voice recognition unit (ASR)
33 Speech synthesis unit (TTS)
34 Telephone board interface (I / F)
50 Telephone terminal 60 Maintenance terminal 100 IP network 200 Public switched telephone network (PSTN)

Claims (8)

An interactive collaborative work support system that supports collaborative work by multiple users,
A dialogue execution unit for inputting / outputting dialogue information with each user by voice;
A plurality of dialog models that manage a dialog model according to each user's role, control the state transition of the user's own dialog model based on dialog information input from the connected user, and generate a new dialog scenario for output to the connected user The dialogue control part of
An interactive collaborative work support system comprising: a synchronous control unit that manages a common condition for a required dialog control unit to make a state transition in synchronization based on dialogue information input from the plurality of users. 2. The interactive collaborative work support system according to claim 1, wherein the synchronization control unit causes the required dialog control unit to transition to the next state based on dialog information input to the effect that the required user has completed the work. 2. The interactive cooperative work support system according to claim 1, wherein the synchronization control unit shifts a required dialogue control unit to a suspended state based on a dialogue information input indicating work suspension by any user. 2. The synchronization control unit according to claim 1, wherein when a failure is detected in a call between any one of the users and the dialogue execution unit, the required dialogue control unit is shifted to a suspended state due to a call failure. Interactive collaborative work support system. 2. The dialogue according to claim 1, wherein the synchronization control unit shifts the current state in the required dialogue control unit to the previous state based on the dialogue information input for returning the work by any user to the previous state. Type collaborative work support system. The dialogue control unit, when the common condition in the synchronization control unit is satisfied, based on the current state managed by the user and the dialogue information input by the user, The interactive collaborative work support system according to claim 1, wherein information to be collected is determined. Provided with a scenario insertion unit that manages a dialogue model for responding to occurrence of a predetermined event, interrupts dialogue processing in a plurality of dialogue control units, and inserts another dialogue scenario to execute dialogue with a plurality of users. The interactive collaborative work support system according to any one of claims 1 to 6. 2. The interactive collaborative work support system according to claim 1, wherein the dialog control unit manages a dialog model corresponding to the skill based on personal information reflecting the skill of the connected user.

Images