Service providing system and method, and vehicle-side device

Abstract

To quickly start software associated with each person boarding a vehicle while avoiding an increase in required resources.SOLUTION: The database holds a plurality of pieces of first software and a second software individually associated with a plurality of persons who board the vehicle. The second software (PDb) is executed in the worker node (22). Thereafter, in a case where it is determined that execution of the first software (PD[i]) corresponding to any target person among the plurality of persons is required, the resource (RSa) allocated to execution of the second software is released to a resource for execution of the first software corresponding to the target person, and then the first software corresponding to the target person is executed by the worker node.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] The present invention relates to a service providing system and method, and a vehicle-side device. [Background technology]

[0002] In a vehicle system, there is a method of setting personalized setting information for each individual through personal authentication, and attempting to provide services suited to each individual (see Patent Document 1 below). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2023-148272 Summary of the Invention [Problem to be solved by the invention]

[0004] One approach is to build software tailored to the preferences of each vehicle occupant and provide desired services to each occupant by running the corresponding software. However, keeping software for all occupants running at all times would be wasteful. Therefore, one approach is to disable the corresponding software for each occupant as a general rule and launch the required software only when necessary. However, this approach can result in a relatively long wait time until the software is fully launched when it is needed, which is inconvenient for the user (occupant).

[0005] An object of the present invention is to provide a technology that enables quick activation of software associated with each person riding in a vehicle while avoiding an increase in required resources. [Means for solving the problem]

[0006] The service providing system according to the present invention includes a vehicle-side device having a first controller and disposed in a vehicle, a database storing multiple first software programs and second software programs individually associated with multiple persons aboard the vehicle, a second controller, and a service management device having a worker node that executes the software in the database under the control of the second controller. The first controller requests the second controller to execute the second software program, and the worker node executes the second software program. If the first controller subsequently determines that the first software program corresponding to any one of the multiple persons needs to be executed, the first controller requests the second controller to start executing the first software program corresponding to the target person. The second controller then releases the resources allocated to the execution of the second software program to resources for executing the first software program corresponding to the target person, and executes the first software program corresponding to the target person on the worker node. [Effects of the Invention]

[0007] By running the second software and then handing over the resources for the second software to the first software when the first software is needed, the first software corresponding to the target person can be quickly launched. This improves user convenience. Because multiple first software programs corresponding to multiple people are not always running, unnecessary resource consumption is also reduced. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is an overall configuration diagram of a service providing system according to an embodiment of the present invention. [Figure 2] FIG. 1 is a diagram showing four people riding in a vehicle according to an embodiment of the present invention. [Figure 3] 1 is a diagram illustrating an internal configuration of an in-vehicle device according to an embodiment of the present invention. [Figure 4]2 is a diagram illustrating an internal configuration of a service management device according to an embodiment of the present invention. [Figure 5] 1 is a diagram illustrating an overview of a dialogue between a vehicle occupant and an dialogue pod according to an embodiment of the present invention. [Figure 6] 1 is a diagram illustrating an overview of a dialogue between a vehicle occupant and an dialogue pod according to an embodiment of the present invention. [Figure 7] 3 is a flowchart of the overall operation of the service providing system according to the embodiment of the present invention. [Figure 8] FIG. 4 is a diagram showing the structure of a registrant table according to the embodiment of the present invention. [Figure 9] FIG. 10 is a diagram illustrating how an interaction pod is launched on a worker node according to an embodiment of the present invention. [Figure 10] 10 is a diagram illustrating possible states of a worker node according to an embodiment of the present invention (when the upper limit number α of balloons is 1). FIG. [Figure 11] 10 is a diagram illustrating possible states of a worker node according to an embodiment of the present invention (when the upper limit number α of balloons is 2). FIG. [Figure 12] 10 is a diagram illustrating possible states of a worker node according to an embodiment of the present invention (when the upper limit number α of balloons is 3). FIG. [Figure 13] 10 is a diagram illustrating possible states of a worker node according to an embodiment of the present invention (when the upper limit number α of balloons is 3). FIG. [Figure 14] FIG. 1 is a diagram showing the flow of operations of a service providing system according to a first example of an embodiment of the present invention. [Figure 15] FIG. 10 is a diagram showing the flow of operations of a service providing system according to a second example of an embodiment of the present invention. [Figure 16] FIG. 10 is a diagram showing the flow of operations of a service providing system according to a second example of an embodiment of the present invention. [Figure 17] 10 is a flowchart illustrating an operation of a controller of an in-vehicle device according to a third example of an embodiment of the present invention. [Figure 18]10 is a flowchart illustrating an operation of a controller of an in-vehicle device according to a third example of an embodiment of the present invention. [Figure 19] 10 is a flowchart illustrating an operation of a master node of a service management device according to a third example belonging to an embodiment of the present invention. [Figure 20] 10 is a flowchart illustrating an operation of a master node of a service management device according to a third example belonging to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, examples of embodiments of the present invention will be described in detail with reference to the drawings. In each of the drawings, identical parts are designated by the same reference numerals, and redundant descriptions of identical parts will be omitted as a general rule. For the sake of simplicity, this specification may use symbols or signs referring to information, signals, physical quantities, functional units, circuits, elements, or components, and may omit or abbreviate the names of the information, signals, physical quantities, functional units, circuits, elements, or components corresponding to the symbols or signs. For example, the service provision system SYS referred to by "SYS" (see FIG. 1) described below may be written as service provision system SYS or abbreviated as system SYS, but they all refer to the same thing.

[0010] FIG. 1 shows a schematic configuration diagram of a service providing system SYS according to this embodiment. The system SYS is provided with an in-vehicle device 10 and a service management device 20, which are vehicle-side devices. The in-vehicle device 10 is disposed in a vehicle VV. The vehicle VV may be any vehicle (such as an automobile) that can travel on roads. The in-vehicle device 10 is installed in an appropriate location inside the vehicle VV, such as in front of the driver's seat. The in-vehicle device 10 may be a device designed to be mounted in the vehicle VV, or may be an information terminal (mobile information terminal) such as a smartphone or tablet brought into the vehicle VV. The in-vehicle device 10 and the service management device 20 are each connected to a communication network NET, which includes a mobile communication line, an intranet, and the Internet. The in-vehicle device 10 and the service management device 20 communicate bidirectionally via the communication network NET.

[0011] A vehicle VV can accommodate up to a predetermined maximum number of passengers, and the vehicle VV is provided with seats that can accommodate that number of passengers. The maximum number of passengers may be any integer greater than or equal to two, but in this embodiment, unless otherwise specified, the maximum number of passengers is assumed to be four. The total number of passengers aboard the vehicle VV is referred to as the number of passengers and is represented by the symbol "β." The number of passengers β is less than or equal to the maximum number of passengers. As shown in FIG. 2, when "β = 4," persons P[1] to P[4] board the vehicle VV. Although not specifically shown, when "β = 3," any three of persons P[1] to P[4] board the vehicle VV. When "β = 2," any two of persons P[1] to P[4] board the vehicle VV. When "β = 1," any one of persons P[1] to P[4] board the vehicle VV. In the following description, an occupant refers to a person riding in a vehicle VV (and therefore person P[1], P[2], P[3] or P[4]).

[0012] A microphone MC, a speaker SP, and a camera CM are arranged in the cabin of the vehicle VV, and are connected to the in-vehicle device 10 by wire or wirelessly.

[0013] The microphone MC converts the sound from the interior of the vehicle VV into an acoustic signal S IN and the acoustic signal S obtained by the conversion of the microphone MC IN When an occupant of the vehicle VV speaks, the occupant's speech is included in the sound in the cabin of the vehicle VV, and therefore the acoustic signal S IN includes an acoustic signal of the speech sound. A microphone MC is placed in an appropriate location in the cabin of the vehicle VV so that the speech sound of the occupant can be properly picked up. The microphone MC may be provided in the in-vehicle device 10. The microphone MC may be provided in an information terminal (smartphone) brought into the vehicle VV. The microphone MC may be composed of multiple microphones.

[0014] The speaker SP receives the audio signal S supplied from the in-vehicle device 10.OUT The speaker SP is arranged in an appropriate location in the cabin of the vehicle VV so that each occupant can hear the output sound of the speaker SP. The speaker SP may be provided in the in-vehicle device 10. The speaker SP may also be provided in an information terminal (smartphone) brought into the vehicle VV. The speaker SP may be composed of multiple speakers.

[0015] The camera CM is a camera that captures each occupant of the vehicle VV within its shooting area, and therefore generates captured images of each occupant of the vehicle VV. The captured images of the camera CM include facial images of each occupant of the vehicle VV. The camera CM takes images sequentially at a predetermined frame rate and transmits the image data of the captured images to the in-vehicle device 10. The camera CM may be provided in the in-vehicle device 10. The camera CM may also be provided in an information terminal (smartphone) brought into the vehicle VV. The camera CM may be composed of multiple cameras.

[0016] 3 shows the internal configuration of the in-vehicle device 10. The in-vehicle device 10 includes a controller 11, a memory 12, a communication unit 13, a recording medium 14, a display unit 15, and an operation unit 16.

[0017] The controller 11 is a vehicle-side controller (first controller) and includes, as hardware resources, a calculation processing unit including a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit). The controller 11 may implement any function, operation, and process that should be implemented by the controller 11 by executing a program recorded in the memory 12 or any other recording medium.

[0018] The memory 12 is configured to include a non-volatile memory such as a ROM (Read Only Memory) or a flash memory, and a volatile memory such as a RAM (Random Access Memory). The memory 12 stores various data referenced by the controller 11 as well as various programs to be executed by the controller 11.

[0019] The communication unit 13 is a communication module that transmits and receives any signal between the in-vehicle device 10 and a counterpart device different from the in-vehicle device 10. The communication unit 13 may be a communication module provided outside the in-vehicle device 10. The communication module provided outside the in-vehicle device 10 may be a communication module shared by the in-vehicle device 10 and other electrical equipment provided in the vehicle VV. The communication unit 13 may be a communication module provided in an information terminal (smartphone) brought into the vehicle VV. The counterpart device for the communication unit 13 includes the service management device 20 shown in FIG. 1. The communication unit 13 can communicate with any device (including the service management device 20) connected to the communication network NET via the communication network NET. The counterpart device for the communication unit 13 may include a microphone MC and a speaker SP. The communication unit 13 may transmit and receive signals to and from the microphone MC and the speaker SP via an in-vehicle network formed in the vehicle VV. The controller 11 can use the communication unit 13 to send and receive any information to and from a partner device, but in the following, the description of the communication unit 13 may be omitted.

[0020] The recording medium 14 is a non-volatile recording medium made of a magnetic disk, flash memory, or the like, and stores (records) any information in a non-volatile manner. The controller 11 is capable of recording any information on the recording medium 14 and reading any information recorded on the recording medium 14. The recording medium 14 may be provided outside the in-vehicle device 10 and inside the vehicle VV. In this case, the controller 11 accesses the recording medium 14 via an in-vehicle network using the communication unit 13. The recording medium 14 may be provided outside the vehicle VV. In this case, the recording medium 14 is connected to a communication network NET, and the controller 11 accesses the recording medium 14 via the communication network NET using the communication unit 13.

[0021] The display unit 15 is a display device formed of a liquid crystal display panel or the like, and displays any image under the control of the controller 11. The display unit 15 may be a display device provided in an information terminal (smartphone) brought into the vehicle VV.

[0022] The operation unit 16 accepts various operations from an operator. The operator is the person who operates the in-vehicle device 10 and is one of the occupants of the vehicle VV. The operation unit 16 may be an operation unit provided on an information terminal (smartphone) brought into the vehicle VV.

[0023] The in-vehicle device 10 can realize multiple functions. For example, the multiple functions may include a navigation process that assists the vehicle VV in traveling to a destination. The multiple functions may also include a drive recording function that records images captured by a camera that captures the exterior or interior of the vehicle VV on a recording medium 14. In addition, various other functions may be realized by the in-vehicle device 10, but in the present embodiment, attention will be focused on an interactive function that is realized by cooperation between the in-vehicle device 10 and the service management device 20.

[0024] 4 shows the configuration of the service management device 20. The service management device 20 includes a master node 21 that functions as a cloud-side controller (second controller), a worker node 22, a pod database 23, and a service management database 24.

[0025] Each of the master node 21 and the worker node 22 is configured with one or more computer devices connected to the communication network NET and can execute any program. The master node 21 and the worker node 22 may be configured with the same computer device or different computer devices. The master node 21 and the worker node 22 may be formed using cloud computing. Any computer device that constitutes the service management device 20 has an arithmetic processing unit including a CPU, GPU, etc., as well as memory and communication units equivalent to the memory 12 and communication unit 13. Any computer device that constitutes the service management device 20 executes a program stored in the memory to perform processing defined in the program. Any computer device that constitutes the service management device 20 can communicate with any device connected to the communication network NET using its own communication unit.

[0026] A container orchestration system is installed in the service management device 20. Here, it is assumed that a container orchestration system based on Kubernetes is installed in the service management device 20. In this case, the service management device 20 corresponds to a Kubernetes cluster.

[0027] The master node 21 manages multiple pods using a container orchestration system. A pod is software that serves as the basic unit of scheduling and has one or more containers. A container is a collection of application programs and libraries required to run the application programs. The master node 21 uses the container orchestration system to manage the deployment and scaling of application programs on a pod-by-pod basis. The master node 21 is a control plane that operates and manages Kubernetes, and manages the overall operation of the service management device 20. The configuration and operation of the control plane are publicly known, so a detailed description will be omitted, but the control plane has components such as an API Server, scheduler, controller manager, and data store (etcd).

[0028] The worker node 22 is a device on which a pod is deployed. The worker node 22 operates under the control of the master node 21 and deploys a pod specified by the master node 21. Deploying a pod on the worker node 22 means executing an application program in the pod on the worker node 22 and placing the application program in a state in which the user can use its functions (hereinafter referred to as an operational state). In the process of placing a pod in an operational state, the master node 21 searches for resources within the worker node 22 for executing the application program in the pod and allocates them to the pod. A user is a user of the system SYS, and in the case of a vehicle VV, this is any or all of the persons P[1] to P[4]. The worker node 22 may be a collection of multiple physically separated nodes.

[0029] The pod database 23 (hereinafter may be abbreviated as database 23) is a recording medium that stores and holds multiple pods. The database 23 may be configured as a single recording medium, or may be configured as multiple recording media. The master node 21 specifies the pod (i.e., software to be executed) to be deployed in the worker node 22. The worker node 22 reads the pod specified by the master node 21 from the database 23 and deploys the read pod, thereby executing the application program in the pod.

[0030] The service management database 24 (hereinafter may be abbreviated as database 24) is a recording medium that stores and holds various data related to the services that the service management device 20 provides to users. The contents stored in the database 24 include a registrant table TBL1 (details will be described later). The services that the service management device 20 provides to users are services using interactive functions. The database 24 may be configured as a single recording medium, or may be configured as multiple recording media. The databases 23 and 24 may also be configured as a common recording medium.

[0031] The multiple pods stored in the database 23 include pods PD[1] to PD[4] and pod PDcom, as well as pod PDb, which may be referred to as a balloon pod. Each of the pods PD[1] to PD[4] and pod PDcom has a dialogue model that realizes dialogue with a person. Each dialogue model can be created using known generation AI (Artificial Intelligence). Pod PDb will be described later, and each dialogue pod will be described below.

[0032] Each of the pods PD[1] to PD[4] is a dialogue pod having a dialogue model customized for the corresponding person, and is software configured to realize a dialogue with the corresponding person. Here, persons P[1], P[2], P[3], and P[4] correspond to pods PD[1], PD[2], PD[3], and PD[4], respectively. That is, pod PD[i] has a dialogue model customized for person P[i] and is software that realizes a dialogue with person P[i] (i represents an arbitrary integer). The service management device 20 can realize a dialogue with person P[i] using pod PD[i]. When pod PD[i] is deployed on the worker node 22, person P[i] can have a dialogue with the dialogue model created by pod PD[i]. The text output content from pod PD[i] is transmitted to person P[i] using speaker SP. That is, the dialogue between person P[i] and pod PD[i] is composed of the speech of person P[i] and the output of text from pod PD[i], and is realized using microphone MC and speaker SP.

[0033] In contrast, the pod PDcom is a dialogue pod with a generic dialogue model that has not been customized as described above, and is software designed to realize dialogue with unspecified people. It can be said that the database 23 holds pods PD[1] to PD[4] individually for people P[1] to P[4], and also holds a common pod PDcom for people P[1] to P[4]. The service management device 20 can also use the pod PDcom to realize dialogue with person P[1], P[2], P[3], or P[4]. When the pod PDcom is deployed on the worker node 22, person P[i] can engage in dialogue with the dialogue model created by the pod PDcom. The text output from the pod PDcom is transmitted to person P[i] using the speaker SP. In other words, the dialogue between person P[i] and the pod PDcom consists of person P[i]'s speech and the text output from the pod PDcom, and is realized using the microphone MC and the speaker SP.

[0034] The flow of the dialogue between the person P[i] and the pod PD[i] will be described with reference to Figure 5. The controller 11 comprises functional blocks F1 to F3. The controller 11 is a program execution device (computer) capable of executing any program. All or part of the functions of the functional blocks F1 to F3 may be realized by the controller 11 executing a program recorded in the memory 12 or any other recording medium. An acoustic signal S generated by a microphone MC is IN are input to the function blocks F1 to F3. The function blocks F1, F2, and F3 are a call determination unit, a speaker identification unit, and a dialogue management unit, respectively.

[0035] The call determination unit F1 receives the acoustic signal S IN The call determination unit F1 performs a call determination process to determine whether any of the passengers has spoken to the system SYS based on the acoustic signal S. When a passenger speaks to the system SYS, he or she first speaks a predetermined wake-up word, and then speaks the necessary content. IN The call determination unit F1 determines whether a wake-up word has been uttered based on the above. In the call determination process, if the call determination unit F1 determines that a wake-up word has been uttered, it determines that the occupant's utterance following the wake-up word is directed to the system SYS. Alternatively, when the occupant speaks to the system SYS, the occupant may speak after inputting a predetermined operation to the operation unit 16 or while inputting the predetermined operation. In this case, the call determination unit F1 involved in the call determination process can determine that the utterance after or during input of the predetermined operation to the operation unit 16 is directed to the system SYS. Alternatively, the call determination unit F1 may use any known method to determine whether the occupant's utterance is directed to the system SYS. Note that an utterance by person P[i] directed to the system SYS is, in other words, an utterance by person P[i] directed to the dialogue pod (PD[i] or PDcom).

[0036] The speaker identification unit F2 acquires images captured by the camera CM as input images. As described above, the camera CM captures images sequentially at a predetermined frame rate, so that a plurality of input images arranged in time series are acquired by the speaker identification unit F2 as an input moving image. The speaker identification unit F2 recognizes the acoustic signal S IN In the speaker identification process, the speaker identification unit F2 receives the acoustic signal S IN Based on the input video, it is determined whether any of the occupants is speaking. If it is determined that any of the occupants is speaking, in the speaker identification process, the speaker identification unit F2 identifies the occupant who is speaking based on the input video and the movement of the mouth of each occupant.

[0037] In the speaker identification process, once the speaker identification unit F2 identifies the occupant who is speaking, it performs personal identification (personal authentication) of the occupant who is speaking based on the input video and personal identification data. The personal identification identifies which of person P[1] to person P[4] the occupant is speaking. The personal identification data is useful for identifying the occupant who is speaking and is stored in advance on the recording medium 14. Alternatively, the personal identification data is stored in a registered person table TBL1 (see FIG. 4) and provided to the speaker identification unit F2 from the master node 21 via the communication network NET. Specifically, the personal identification data may include facial feature data indicating the facial features of each of person P[1] to person P[4]. Using the input video and facial feature data, the speaker identification unit F2 can identify which of person P[1] to person P[4] each occupant is, using well-known face recognition technology. Here, we focus only on person P[1] to person P[4], but in reality, the speaker identification unit F2 can identify which person the speaking passenger is from a group of people consisting of person P[1] to person P[4] and a large number of other people.

[0038] The result of identifying the individual passenger who is speaking is input from the speaker identification unit F2 to the dialogue management unit F3. This allows the dialogue management unit F3 to determine whether any of the persons P[1] to P[4] is speaking and who the person is. The result of the call determination process by the call determination unit F1 is also input to the dialogue management unit F3. When person P[1] speaks to the system SYS, the dialogue management unit F3 can determine that person P[1] spoke to the system SYS based on the input contents from the call determination unit F1 and the speaker identification unit F2. Similarly, when person P[2] speaks to the system SYS, the dialogue management unit F3 can determine that person P[2] spoke to the system SYS based on the input contents from the call determination unit F1 and the speaker identification unit F2. The same applies to person P[3], etc.

[0039] In the following description, unless otherwise specified, an utterance is an utterance made by a speaker directed to the system SYS. Unless otherwise specified, a speaker refers to a person among the occupants of the vehicle VV who has spoken to the system SYS. For the sake of concreteness, a case in which person P[i] has spoken to the system SYS will be referred to as utterance case CS[i]. Therefore, the speaker in utterance case CS[i] is person P[i]. Multiple speakers may occur at the same time. In utterance case CS[i], the dialogue management unit F3 transmits utterance information 610 indicating the content of the utterance made by person P[i] to the service management device 20. The utterance information 610 preferably includes utterance text data indicating the content of the utterance made by person P[i]. The dialogue management unit F3 can generate the utterance text data. However, the speech information 610 may be an audio signal indicating the content of the speech of the person P[i], and in this case, the worker node 22 may generate speech text data based on the audio signal in the speech information 610.

[0040] 5, the worker node 22 in the service management device 20 has completed activation of the pod PD[i], and a dialogue between the person P[i] and the pod PD[i] is now possible. Therefore, the utterance information 610 is input to the dialogue model in the pod PD[i], and the dialogue model in the pod PD[i] generates pod output information 620 in response to the utterance information 610. The master node 21 transmits the generated pod output information 620 to the in-vehicle device 10. The pod output information 620 received by the in-vehicle device 10 is input to the dialogue management unit F3.

[0041] The pot output information 620 includes a response sentence that is a sentence that responds to the utterance information 610. The pot output information 620 may include text data of the response sentence. The dialogue management unit F3 generates an audio signal S indicating the text data of the response sentence. OUT The pot output information 620 may include an audio signal of a sentence that responds to the speech information 610. In this case, the dialogue management unit F3 converts the audio signal of the sentence into an audio signal S OUT The sentence may be transmitted to the person P[i] by supplying the sentence to the speaker SP as

[0042] In the utterance case CS[i], the startup of the pod PD[i] may not be completed in the worker node 22 of the service management device 20. During the period in which the startup of the pod PD[i] is not completed in the utterance case CS[i], a dialogue takes place between the pod PDcom, which is a general-purpose dialogue pod, and the person P[i], as shown in FIG. 6. During the period in which the startup of the pod PD[i] is not completed in the utterance case CS[i], the utterance information 610 is input to the dialogue model in the pod PDcom, and the dialogue model in the pod PDcom generates pod output information 630 in response to the utterance information 610. The master node 21 transmits the generated pod output information 630 to the in-vehicle device 10. The pod output information 630 received by the in-vehicle device 10 is input to the dialogue management unit F3.

[0043] The pot output information 630 includes response text data, which is text data of a sentence responding to the utterance information 610. The dialogue management unit F3 generates an acoustic signal S indicating the response text data of the pot output information 630. OUT The pod output information 630 may include an audio signal of a sentence responding to the speech information 610, and in this case, the dialogue management unit F3 converts the audio signal of the sentence into an audio signal S. OUT The sentence may be transmitted to the person P[i] by supplying the sentence to the speaker SP as

[0044] Figure 7 shows a schematic flowchart of the operation of the system SYS. In the system SYS, a user registration process is first carried out in step S1. Any person who wishes to receive services from the system SYS is registered in the system SYS in advance in the user registration process, and the registration details are stored in the registrant table TBL1.

[0045] Figure 8 shows the structure of the registrant table TBL1 stored in the database 24. The user registration process is carried out by a registration device connected to the communication network NET. Although not specifically shown, the registration device is included in the components of the system SYS. The registration device may be the master node 21 or another computer device.

[0046] For convenience, any person who wishes to receive services from System SYS will be referred to as a registration applicant. The registration applicant, or an agent acting on behalf of the registration applicant, provides the necessary registration information to the registration device through any terminal device. The registration information of the registration applicant includes the registration applicant's personal information. The registration applicant's personal information includes the registration applicant's name, address, and contact information. The registration applicant's contact information represents the registration applicant's contact information when System SYS communicates any information to the registration applicant. The registration applicant's contact information includes the telephone number or email address assigned to the terminal device owned by the registration applicant, or the account information for an instant messenger running on the terminal device.

[0047] The personal information of the person wishing to register further includes attribute information of the person wishing to register. The attribute information of the person wishing to register includes the age (which may be an age group), gender, nationality, language used, dialect used, preference information, etc. of the person wishing to register. The language used by the person wishing to register is the language (Japanese or English, etc.) that the person wishing to register primarily uses in conversation. The dialect used by the person wishing to register is the dialect that the person wishing to register primarily uses in conversation. The preference information of the person wishing to register represents the preferences of the person wishing to register.

[0048] In the user registration process, the registration device assigns a unique identification ID to each person wishing to register, and stores the person's personal information in a registrant table TBL1 in association with the corresponding identification ID. The registration device also stores additional information about the person wishing to register in the registrant table TBL1, in association with the corresponding identification ID, as needed. The additional information about the person wishing to register may include any information (such as payment information related to the use of services provided by the system SYS).

[0049] The user registration process is carried out for each person wishing to register. Here, the people corresponding to the identification IDs "0001", "0002", "0003", and "0004" are assumed to be people P[1], P[2], P[3], and P[4], respectively. However, there are cases where a single representative person (e.g., P[1]) among multiple people wishing to register collectively inputs the information required for the user registration process for multiple people wishing to register (e.g., P[1] to P[4]). Note that some elements of the personal information of a person wishing to register (e.g., age or nationality) may not be stored in the registrant table TBL1.

[0050] Following the user registration process of step S1, a pod matching process of step S2 is carried out. In the pod matching process, the matching device creates a pod having an interaction model that matches the registered person and performs a matching process to match the registered person. The pod matching process includes a customization process. The customization process is carried out by a customization device connected to the communication network NET, and the pod matching process is carried out by a matching device connected to the communication network NET. Although not specifically shown, the customization device and the matching device are included as components of the system SYS. The customization device may be the master node 21 or another computer device. The matching device may be the master node 21 or another computer device. The customization device and the matching device may be the same computer device. A registration applicant who has completed the user registration process and has been registered in the system SYS is called a registered person.

[0051] In the customization process, the customization device uses, for example, a general-purpose pod (which may be a pod PDcom) having a dialogue model to have a dialogue with the person who has completed registration, and customizes the general-purpose pod to suit the preferences of the person who has completed registration based on the content of the dialogue. Then, in the association process, the association device associates this customized pod with the person who has completed registration. The association process is performed for each person who has completed registration. Therefore, if we focus on persons P[1] to P[4], the association process is performed for each of persons P[1] to P[4] in the pod association process.

[0052] Pod PD[i] is a pod associated with person P[i], who has completed registration, by performing an association process on person P[i]. The association device stores each pod generated during the association process in database 23, while storing the association relationship between each registered person and the pod in registrant table TBL1. As a result, in registrant table TBL1, pod PD[1] is associated with person P[1] corresponding to the identification ID of "0001." Similarly, in registrant table TBL1, pod PD[2] is associated with person P[2] corresponding to the identification ID of "0002." Similarly, in registrant table TBL1, pod PD[3] is associated with person P[3] corresponding to the identification ID of "0003." Similarly, in registrant table TBL1, pod PD[4] is associated with person P[4] corresponding to the identification ID of "0004."

[0053] Any customization method, including known methods, may be used to customize a dialogue model to suit a specific person. The customization device may perform customization based on instructions from a registered person. The association process may be performed using the following method. For example, the customization device or the association device may prepare multiple types of dialogue pods, each having a dialogue model. Then, for each registered person, the customization device or the association device may select a dialogue pod that suits the registered person from multiple types of dialogue pods based on the registered person's attribute information, and associate the selected dialogue pod with the registered person. When using this method, the dialogue pod selected for person P[i] becomes pod PD[i].

[0054] After the pod correspondence process of step S2, the service operation process of step S3 is performed. At the stage when the service operation process is performed, the registrant table TBL1 in the state shown in FIG. 8 has already been stored in the database 24, and the pods PD[1] to PD[4] have already been stored in the database 23 as shown in FIG. 4. Except for the operations of the registration device, customization device, and correspondence device, the operations of each device described in this embodiment are operations performed in the service operation process unless otherwise specified. In the service operation process, a dialogue between people and dialogue models as shown in FIGS. 5 and 6 takes place. In the service operation process, the master node 21 may update (customize) the dialogue model of pod PD[i] based on the content of the dialogue between person P[i] and the dialogue model of pod PD[i].

[0055] However, deploying a pod having a dialogue model requires a corresponding amount of resources from the worker node 22. On the other hand, it is considered rare for a crew member to constantly need to interact with the dialogue model. For this reason, setting the pod corresponding to each crew member to be in operation at all times on the worker node 22 would be a significant waste of resources.

[0056] However, when a scheduler in the container orchestration system executes scheduling for the execution of pod PD[i] after detecting a call from person P[i] to system SYS, it may take a long time for the startup of pod PD[i] to be completed. Upon receiving a request to execute (deploy) pod PD[i], the scheduler determines whether the worker node 22 has the resources necessary to execute pod PD[i] and, if necessary, formulates an execution plan for pod PD[i] through arbitration related to resource contention, etc. The master node 21 allocates the resources necessary for pod PD[i] in accordance with the created execution plan and executes (deploys) pod PD[i] on the worker node 22. Following this procedure may take a long time for the startup of pod PD[i] to be completed. The worker node 22 is a node shared for the execution of a large number of pods, and may not always be able to respond immediately to an execution request for pod PD[i]. If the resources required for the pod PD[i] cannot be immediately secured, the execution of the pod PD[i] may be put on hold until the resources required for the pod PD[i] are released.

[0057] Considering this, the system SYS uses pod PDb. Pod PDb is a pod called a balloon pod in the Kubernetes container orchestration system. Pod PDb does not have any significant functionality, and the execution of application programs within pod PDb does not involve interactions with person P[i].

[0058] FIG. 9 is a conceptual diagram of how a pod PDb is used in the system SYS. First, the pod PDb is deployed to the worker node 22, whereby the pod PDb is executed on the worker node 22, thereby reaching state ST1. In FIG. 9, "RSa" represents resources allocated to the execution of the pod PDb. The resources are computational resources possessed by the worker node 22. The computational resources include a processor and memory provided in the worker node 22. The resources allocated to the execution of the pod PDb refer to the computational resources allocated to the execution of the pod PDb among all the computational resources possessed by the worker node 22. After reaching state ST1, when a start request (execution request) for the pod PD[i] is generated, the master node 21 controls the worker node 22 to surrender the resource RSa allocated to the execution of the pod PDb to the resource for executing the pod PD[i]. In addition, the master node 21 controls the worker node 22 to execute the pod PD[i] using the resource RSa. Therefore, the worker node 22 deploys the pod PD[i] using the resource RSa, thereby executing the pod PD[i], which leads to the state ST2. In the state ST2, the pod PD[i] is in an active state. The pod PD[i] in an active state can interact with the person P[i].

[0059] After the transition from state ST1 to state ST2, if resource RSb for deploying pod PDb remains in the worker node 22, the master node 21 may transition the state of the worker node 22 from state ST2 to state ST3. In state ST3, pod PD[i] is running in resource RSa and is in operation, and pod PDb is running in resource RSb and is in operation.

[0060] The size of resource RSa is equal to or greater than the size of the resources required to execute pod PD[i]. That is, the size of the resources allocated to the execution of pod PDb is equal to or greater than the size of the resources allocated to the execution of pod PD[i]. Therefore, a transition from state ST1 to state ST2 is possible, and therefore pod PD[i] can be quickly started. In the following, it is assumed that the size of the resources allocated to the execution of pod PDb is the same as the size of the resources allocated to the execution of pod PD[i].

[0061] Any pod includes a setting definition file (setting information). For any pod of interest, the setting definition file includes resource information, which specifies the size of resources required to execute the pod of interest (such as the required CPU occupancy rate or number of cores, the required amount of memory, etc.). When executing a pod of interest, the master node 21 reserves the resources required to execute the pod of interest within the worker node 22 based on the resource information of the pod of interest.

[0062] Therefore, when transitioning pod PDb from the non-execution state to state ST1, the master node 21 secures resources RSa necessary to execute pod PDb in the worker node 22 based on the resource information in the setting definition file of pod PDb. The size of resources RSa is equal to or greater than the size of resources specified in the resource information of pod PDb. After that, when a start request (execution request) for pod PD[i] occurs, the master node 21 attempts to secure resources necessary to execute pod PD[i].

[0063] Here, a priority can be defined in the setting definition file of each pod. In fact, a priority is defined in the setting definition file of pods PD[1] to PD[4], and a priority is also defined in the setting definition file of pod PDb. The priorities in the setting definition files of pods PD[1] to PD[4] are all higher than the priority in the setting definition file of pod PDb. When a pod with a relatively low priority is being executed and a pod with a relatively high priority is requested to be executed, the master node 21 stops the execution of the former pod and gives up the resources of the former pod to the resources of the latter pod.

[0064] Therefore, when a startup request (execution request) for pod PD[i] occurs in state ST1, the master node 21 controls the worker node 22 to release the resource RSa allocated to the execution of pod PDb to the resource for executing pod PD[i]. In other words, when startup of pod PD[i] is requested, the master node 21 allocates the resource RSa of the worker node 22 preferentially to pod PD[i], which has a relatively higher priority, over pod PDb, which has a relatively lower priority. This enables the pod PD[i] to be started up quickly.

[0065] The priority of the pod PDcom is the same as or higher than the priority of the pod PD[i]. Alternatively, a priority may not be set for the pod PDcom. In either case, even if a startup request (execution request) for the pod PD[i] or PDb occurs while the pod PDcom is running, the execution of the pod PDcom is not interrupted.

[0066] The use of pods PDb, which correspond to balloon pods, allows for the prompt launch of necessary dialogue pods. However, launching more pods PDb than necessary puts strain on the remaining resources of the worker node 22. For this reason, the system SYS defines an upper limit number of balloons α, so that pods PDb exceeding the upper limit number of balloons α are not executed on the worker node 22. The upper limit number of balloons α has an integer value greater than or equal to 1. Before using the system SYS (e.g., during the user registration process), a user of the system SYS enters into a contract for the upper limit number of balloons α with the system SYS operator. Among persons P[1] to P[4], person P[1] is assumed to be the representative. In this case, person P[1] enters into a contract for the upper limit number of balloons α with the system SYS operator. The determined upper limit number of balloons α is stored in the registrant table TBL1 by the registration device in association with person P[1]. The upper limit number of balloons α can also be stored in the recording medium 14 in the in-vehicle device 10. The upper limit number of balloons α corresponding to person P[1] is applied to the vehicle VV in which person P[1] rides. Therefore, when person P[1] and another person get into vehicle VV, the balloon upper limit number α corresponding to person P[1] (the balloon upper limit number α stored in registered person table TBL1 in association with person P[1]) is applied to all occupants of vehicle VV.

[0067] As will be clear from the following explanation, if "α = 1," a dialogue pod corresponding to the first crew member's speech is quickly activated, but the corresponding dialogue pod may not be quickly activated in response to the second crew member's speech. Similarly, if "α = 2," two dialogue pods corresponding to the first and second crew members' speech are quickly activated, but the corresponding dialogue pod may not be quickly activated in response to the third crew member's speech. For this reason, a larger balloon upper limit α is preferable for crew members, but increasing the balloon upper limit α leads to increased resource consumption by the worker node 22 (increasing costs for the operating company). For this reason, a user (person P[1]) who negotiates the balloon upper limit α with the operator of System SYS will pay a larger service usage fee to the operator of System SYS the larger the balloon upper limit α. The service usage fee is the fee for using the services of System SYS. The user arbitrarily determines the balloon upper limit α taking cost-effectiveness into consideration.

[0068] Fig. 10 lists the states that the worker node 22 can take when the upper limit number of balloons α is 1. Fig. 11 lists the states that the worker node 22 can take when the upper limit number of balloons α is 2. Fig. 12 lists the states that the worker node 22 can take when the upper limit number of balloons α is 3. Fig. 13 lists the states that the worker node 22 can take when the upper limit number of balloons α is 4.

[0069] As mentioned above, the number of passengers β represents the total number of people aboard the vehicle VV. The number of running dialogue pods γ is the total number of pods running in the worker node 22 among the pods PD[1] to PD[4]. The number of running dialogue pods γ is less than or equal to the number of passengers β. The state of the worker node 22 is represented by state ST[x,y,z]. State ST[x,y,z] refers to a state in which the upper limit number of balloons α is x, the number of passengers β is y, and the number of running dialogue pods γ is z. x and y represent integers greater than or equal to 1, and z represents an integer greater than or equal to 0. The worker node 22 has resources RS0 to RS4. The pod PDcom is always assigned to resource RS0, and the worker node 22 always executes the pod PDcom to keep the pod PDcom in operation. Therefore, regardless of the values ​​of α, β, and γ, in any state ST[α,β,γ], the pod PDcom is always assigned to the resource RS0, and the worker node 22 executes the pod PDcom to put the pod PDcom into operation. The pod PDcom is used for communication with the crew when, for example, the startup of the pod PD[i] cannot be made in time.

[0070] In the following, when "β = 1", it is assumed that person P[1] gets into vehicle VV. When "β = 2", it is assumed that people P[1] and P[2] get into vehicle VV. When "β = 3", it is assumed that people P[1] to P[3] get into vehicle VV. When "β = 4", it is assumed that people P[1] to P[4] get into vehicle VV. Figures 10 to 13 will be explained under the following speech order assumption. Under this speech order assumption, when "β = 2", it is assumed that person P[1] speaks to system SYS, followed by person P[2]. Under this speech order assumption, when "β = 3", it is assumed that person P[1] speaks to system SYS, followed by person P[2], and then person P[3] speaks. In this speech order assumption, when "β=4", it is assumed that person P[1] speaks to the system SYS, followed by person P[2], and then person P[3] speaks, followed by person P[4].

[0071] --In the case of "α=1"-- 10, the state of the worker node 22 when "α=1" will be described in detail. When "α=1", the total number of pods PDb executed on the worker node 22 is a maximum of 1 (=α).

[0072] When "α=1" and "β=1", then "γ=0" or "γ=1" is true. In state ST[1,1,0], pod PDb is assigned to resource RS1, and the worker node 22 executes pod PDb to place pod PDb in operation. In state ST[1,1,0], no resources are assigned to pods PD[1] to PD[4]. Starting from state ST[1,1,0], when person P[1] speaks, resource RS1, which was assigned to pod PDb, is handed over to pod PD[1], and pod PD[1] is executed by resource RS1, thereby reaching state ST[1,1,1]. That is, in state ST[1,1,1], pod PD[1] is assigned to resource RS1, and the worker node 22 executes pod PD[1] to place pod PD[1] in operation. In state ST[1,1,1], no resources are allocated to pods PD[2] to PD[4]. If "β=γ", no new dialogue pods are launched, and therefore no resources are allocated to pod PDb in state ST[1,1,1]. Pods to which no resources are allocated are in a non-executing state. However, if "α=1" and "β=1", the master node 21 may always set the state of the worker node 22 to state ST[1,1,1] even if person P[1] has not spoken. This is because the amount of resources required is the same between states ST[1,1,0] and ST[1,1,1].

[0073] When "α=1" and "β=2", "γ=0", "γ=1", or "γ=2" is assumed. In state ST[1,2,0], pod PDb is assigned to resource RS1, and the worker node 22 executes pod PDb to place pod PDb in operation. In state ST[1,2,0], no resources are assigned to pods PD[1] to PD[4]. When person P[1] speaks starting from state ST[1,2,0], resource RS1, which was assigned to pod PDb, is handed over to pod PD[1], and pod PD[1] is executed by resource RS1. After that, resource RS2 is newly assigned to pod PDb, resulting in state ST[1,2,1]. That is, in state ST[1,2,1], pods PD[1] and PDb are assigned to resources RS1 and RS2, and the worker node 22 executes pods PD[1] and PDb to place them in operation. In state ST[1,2,1], no resources are allocated to pods PD[2] to PD[4]. When person P[2] speaks starting from state ST[1,2,1], resource RS2, which was allocated to pod PDb, is handed over to pod PD[2], and pod PD[2] is executed by resource RS2, thereby reaching state ST[1,2,2]. That is, in state ST[1,2,2], pods PD[1] and PD[2] are allocated to resources RS1 and RS2, and worker node 22 executes pods PD[1] and PD[2], putting them into an active state. In state ST[1,2,2], no resources are allocated to pods PD[3] and PD[4]. If "β = γ", no new dialogue pods are launched, and therefore no resources are allocated to pod PDb in state ST[1,2,2].

[0074] Note that, when person P[1] speaks starting from state ST[1,2,0], the master node 21 may transition the state of the worker node 22 to state ST[1,2,2] via state ST[1,2,1] even if person P[2] does not speak, because the size of the required resources is the same between states ST[1,2,1] and ST[1,2,2].

[0075] When "α=1" and "β=3", "γ=0", "γ=1", "γ=2" or "γ=3" are possible. State ST[1,3,0] is the same as state ST[1,2,0]. Starting from state ST[1,3,0], when person P[1] speaks, the state transitions to state ST[1,3,1]. State ST[1,3,1] is the same as state ST[1,2,1], and the operation from state ST[1,3,0] to state ST[1,3,1] is the same as the operation from state ST[1,2,0] to state ST[1,2,1]. Starting from state ST[1,3,1], when person P[2] speaks, the resource RS2 that was allocated to pod PDb is handed over to pod PD[2], and pod PD[2] is executed by resource RS2. After that, resource RS3 is newly assigned to pod PDb, resulting in state ST[1,3,2]. That is, in state ST[1,3,2], pods PD[1], PD[2], and PDb are assigned to resources RS1, RS2, and RS3, and the worker node 22 executes pods PD[1], PD[2], and PDb, putting them in operation. In state ST[1,3,2], no resources are assigned to pods PD[3] and PD[4]. Starting from state ST[1,3,2], when person P[3] speaks, resource RS3, which was assigned to pod PDb, is handed over to pod PD[3], and pod PD[3] is executed by resource RS3, resulting in state ST[1,3,3]. That is, in state ST[1,3,3], pods PD[1] to PD[3] are assigned to resources RS1 to RS3, and the worker node 22 executes pods PD[1] to PD[3], putting them into operation. In state ST[1,3,3], no resources are assigned to pod PD[4]. If "β=γ", no new interactive pods are launched, and therefore no resources are assigned to pod PDb in state ST[1,3,3].

[0076] Note that, when person P[2] speaks starting from state ST[1,3,1], the master node 21 may transition the state of the worker node 22 to state ST[1,3,3] via state ST[1,3,2] even if person P[3] does not speak, because the size of the required resources is the same between states ST[1,3,2] and ST[1,3,3].

[0077] When "α=1", if "β=4", then "γ=0", "γ=1", "γ=2", "γ=3" or "γ=4". State ST[1,4,0] is the same as state ST[1,3,0]. Starting from state ST[1,4,0], if person P[1] speaks, the state transitions to state ST[1,4,1]. State ST[1,4,1] is the same as state ST[1,3,1], and the operation from state ST[1,4,0] to state ST[1,4,1] is the same as the operation from state ST[1,3,0] to state ST[1,3,1]. Starting from state ST[1,4,1], if person P[2] speaks, the state transitions to state ST[1,4,2]. State ST[1,4,2] is the same as state ST[1,3,2], and the operations from state ST[1,4,1] to state ST[1,4,2] are the same as the operations from state ST[1,3,1] to state ST[1,3,2]. When person P[3] speaks starting from state ST[1,4,2], resource RS3, which was assigned to pod PDb, is handed over to pod PD[3], and pod PD[3] is executed by resource RS3. After that, resource RS4 is newly assigned to pod PDb, resulting in state ST[1,4,3]. That is, in state ST[1,4,3], pods PD[1], PD[2], PD[3], and PDb are assigned to resources RS1, RS2, RS3, and RS4, and the worker node 22 executes pods PD[1] to PD[3] and PDb, putting them into an operating state. In state ST[1,4,3], no resources are allocated to pod PD[4]. When person P[4] speaks starting from state ST[1,4,3], resource RS4, which was allocated to pod PDb, is handed over to pod PD[4], and pod PD[4] is executed by resource RS4, thereby reaching state ST[1,4,4]. That is, in state ST[1,4,4], pods PD[1] to PD[4] are allocated to resources RS1 to RS4, and worker node 22 executes pods PD[1] to PD[4], putting them into an active state. If "β = γ", no new dialogue pods are launched, and therefore no resources are allocated to pod PDb in state ST[1,4,4].

[0078] Note that, when person P[3] speaks starting from state ST[1,4,2], the master node 21 may transition the state of the worker node 22 to state ST[1,4,4] via state ST[1,4,3] even if person P[4] does not speak, because the size of the required resources is the same between states ST[1,4,3] and ST[1,4,4].

[0079] --In the case of "α=2"-- 11, the state of the worker node 22 when "α=2" will be described in detail. When "α=2", the total number of pods PDb executed by the worker node 22 is a maximum of 2 (=α).

[0080] When "α=2" and "β=1", then "γ=0" or "γ=1" is true. In state ST[2,1,0], pod PDb is assigned to resource RS1, and the worker node 22 executes pod PDb, thereby putting pod PDb into operation. In state ST[2,1,0], no resources are assigned to pods PD[1] to PD[4]. Starting from state ST[2,1,0], when person P[1] speaks, resource RS1, which was assigned to pod PDb, is handed over to pod PD[1], and pod PD[1] is executed by resource RS1, thereby reaching state ST[2,1,1]. That is, in state ST[2,1,1], pod PD[1] is assigned to resource RS1, and the worker node 22 executes pod PD[1], thereby putting pod PD[1] into operation. In state ST[2,1,1], no resources are allocated to pods PD[2] to PD[4]. If "β=γ", no new dialogue pods are launched, and therefore no resources are allocated to pod PDb in state ST[2,1,1]. Pods to which no resources are allocated are in a non-executing state. However, if "α=2" and "β=1", the master node 21 may always set the state of the worker node 22 to state ST[2,1,1] even if person P[1] has not spoken. This is because the amount of resources required is the same between states ST[2,1,0] and ST[2,1,1].

[0081] When "α=2" and "β=2", "γ=0", "γ=1", or "γ=2" is assumed. In state ST[2,2,0], pod PDb is assigned to each of resources RS1 and RS2, and the worker node 22 executes the two pods PDb, thereby putting the two pods PDb into operation. In state ST[2,2,0], no resources are assigned to pods PD[1] to PD[4]. Starting from state ST[2,2,0], when person P[1] speaks, resource RS1, which was assigned to pod PDb, is handed over to pod PD[1], and pod PD[1] is executed by resource RS1, thereby reaching state ST[2,2,1]. That is, in state ST[2,2,1], pods PD[1] and PDb are assigned to resources RS1 and RS2, and the worker node 22 executes pods PD[1] and PDb, thereby putting them into operation. In state ST[2,2,1], no resources are allocated to pods PD[2] to PD[4]. If "β=2", there is no possibility of executing a dialogue pod on resource RS3. Therefore, in state ST[2,2,1], pod PDb is not allocated to resource RS3, and the number of executions of pod PDb on worker node 22 is 1. Starting from state ST[2,2,1], when person P[2] speaks, resource RS2, which was allocated to pod PDb, is handed over to pod PD[2], and pod PD[2] is executed by resource RS2, thereby reaching state ST[2,2,2]. That is, in state ST[2,2,2], pods PD[1] and PD[2] are allocated to resources RS1 and RS2, and worker node 22 executes pods PD[1] and PD[2], putting them into an active state. In state ST[2,2,2], no resources are allocated to pods PD[3] and PD[4]. If "β=γ", no new interactive pods will be started, and therefore no resources will be allocated to pod PDb in state ST[2,2,2].

[0082] Note that, when person P[1] speaks starting from state ST[2,2,0], the master node 21 may transition the state of the worker node 22 to state ST[2,2,2] via state ST[2,2,1] even if person P[2] does not speak. This is because the amount of required resources is equivalent between states ST[2,2,1] and ST[2,2,2]. Furthermore, when "α=2" and "β=2", the master node 21 may always set the state of the worker node 22 to state ST[2,2,2] even if person P[1] or P[2] does not speak. This is because the amount of required resources is equivalent between states ST[2,2,0], ST[2,2,1], and ST[2,2,2].

[0083] When "α=2" and "β=3", "γ=0", "γ=1", "γ=2", or "γ=3" is assumed. State ST[2,3,0] is the same as state ST[2,2,0]. When person P[1] speaks starting from state ST[2,3,0], resource RS1, which was assigned to pod PDb, is handed over to pod PD[1], and pod PD[1] is executed by resource RS1. After that, resource RS3 is newly assigned to pod PDb, resulting in state ST[2,3,1]. That is, in state ST[2,3,1], pod PD[1] is assigned to resource RS1, and pod PDb is assigned to each of resources RS2 and RS3. In state ST[2,3,1], the worker node 22 executes pod PD[1] and two pods PDb, putting them into an operational state. In state ST[2,3,1], no resources are allocated to pods PD[2] to PD[4]. When person P[2] speaks starting from state ST[2,3,1], resource RS2, which was allocated to pod PDb, is handed over to pod PD[2], and pod PD[2] is executed by resource RS2, thereby reaching state ST[2,3,2]. That is, in state ST[2,3,2], pods PD[1], PD[2], and PDb are allocated to resources RS1, RS2, and RS3, respectively. In state ST[2,3,2], the worker node 22 executes pods PD[1], PD[2], and PDb, putting them into an active state. In state ST[2,3,2], no resources are allocated to pods PD[3] and PD[4]. If "β=3", there is no possibility of executing an interactive pod on resource RS4. Therefore, in state ST[2,3,2], pod PDb is not assigned to resource RS4, and the number of executions of pod PDb in worker node 22 is 1. When person P[3] speaks starting from state ST[2,3,2], resource RS3, which was assigned to pod PDb, is handed over to pod PD[3], and pod PD[3] is executed by resource RS3, thereby reaching state ST[2,3,3].That is, in state ST[2,3,3], pods PD[1] to PD[3] are assigned to resources RS1 to RS3, and the worker node 22 executes pods PD[1] to PD[3], putting them into operation. In state ST[2,3,3], no resources are assigned to pod PD[4]. If "β=γ", no new interactive pods are launched, and therefore no resources are assigned to pod PDb in state ST[2,3,3].

[0084] Note that, when person P[1] speaks starting from state ST[2,3,0], the master node 21 may transition the state of the worker node 22 to state ST[2,3,3] via state ST[2,3,1] even if person P[2] or P[3] does not speak. This is because the amount of required resources is the same among state ST[2,3,1], state ST[2,3,2], and state ST[2,3,3].

[0085] When "α=2", if "β=4", then "γ=0", "γ=1", "γ=2", "γ=3" or "γ=4". State ST[2,4,0] is the same as state ST[2,3,0]. Starting from state ST[2,4,0], if person P[1] speaks, the state transitions to state ST[2,4,1]. State ST[2,4,1] is the same as state ST[2,3,1], and the operation from state ST[2,4,0] to state ST[2,4,1] is the same as the operation from state ST[2,3,0] to state ST[2,3,1]. Starting from state ST[2,4,1], if person P[2] speaks, the state transitions to state ST[2,4,2]. Except for the first difference described below, state ST[2,4,2] is the same as state ST[2,3,2], and the operations from state ST[2,4,1] to state ST[2,4,2] are the same as the operations from state ST[2,3,1] to state ST[2,3,2]. The first difference is that in state ST[2,4,2], pods PD[1] and PD[2] are assigned to resources RS1 and RS2, and pod PDb is assigned to resources RS3 and RS4, respectively. Therefore, the worker node 22 in state ST[2,4,2] executes pods PD[1] and PD[2] and two pods PDb, putting them into an active state. Starting from state ST[2,4,2], when person P[3] speaks, the state transitions to state ST[2,4,3]. Except for the second difference described below, state ST[2,4,3] is the same as state ST[2,3,3], and the operations from state ST[2,4,2] to state ST[2,4,3] are the same as the operations from state ST[2,3,2] to state ST[2,3,3]. The second difference is that in state ST[2,4,3], pods PD[1] to PD[3] are assigned to resources RS1 to RS3, and pod PDb is assigned to resource RS4. Therefore, the worker node 22 in state ST[2,4,3] runs pods PD[1] to PD[3] and one pod PDb, putting them in an active state. Starting from state ST[2,4,3], when person P[4] speaks, resource RS4, which was assigned to pod PDb, is released to pod PD[4], and pod PD[4] is executed by resource RS4, thereby leading to state ST[2,4,4].That is, in state ST[2,4,4], pods PD[1] to PD[4] are assigned to resources RS1 to RS4, and the worker node 22 puts pods PD[1] to PD[4] into operation by executing them. If "β=γ", no new interactive pods are started, so no resources are assigned to pod PDb in state ST[2,4,4].

[0086] Note that, when person P[2] speaks starting from state ST[2,4,1], the master node 21 may transition the state of the worker node 22 to state ST[2,4,4] via state ST[2,4,2] even if there is no speech from person P[3] or P[4]. This is because the amount of required resources is the same among state ST[2,4,2], state ST[2,4,3], and state ST[2,4,4].

[0087] --Generalization of state ST[α,β,γ]-- Although individual explanations will be omitted, when "α=3" or "α=4", the state of the worker node 22 is set in the same way as when "α=1" and "α=2". Below, the contents of the state ST[α,β,γ] that applies to any balloon upper limit number α, number of passengers β, and number of dialogue pods running γ are described.

[0088] In any state ST[α, β, γ], the number of running pods PDb in the worker node 22 is equal to or less than the upper balloon limit number α.

[0089] When "β = γ", no resources are allocated to pod PDb in the worker node 22, and therefore the number of executions of pod PDb is zero. In other words, during the period when the corresponding dialogue pod is being executed for all persons aboard the vehicle VV (hereinafter referred to as the full operation period), pod PDb is not executed in the worker node 22. This is because there is no benefit to executing pod PDb during the full operation period, and by not executing pod PDb during the full operation period, unnecessary resource consumption is avoided. During the full operation period, "β = γ". For example, the period when the state of the worker node 22 is state ST[1,2,2], ST[1,3,3], ST[2,2,2], or ST[2,3,3] corresponds to the full operation period (see Figures 10 and 11).

[0090] A period different from the full operation period is referred to as a non-full operation period. For example, a period in which the states of the worker node 22 are ST[1,2,1], ST[1,3,1], ST[1,3,2], ST[2,2,1], ST[2,3,1], and ST[2,3,2] corresponds to a non-full operation period (see FIGS. 10 and 11). During the non-full operation period, the master node 21 executes pods PDb on the worker node 22 by the smaller of the upper limit number of balloons α and the difference (β-γ). This allows resources for pod PDb to be handed over to pod PD[i], thereby realizing fast startup of the interactive pod (customized interactive pod), while suppressing excessive execution of pod PDb (suppressing unnecessary resource consumption).

[0091] The difference (β-γ) is a value obtained by subtracting the number of dialogue pods being executed γ from the number of passengers β. For example, in state ST[2,3,1], since "α=2" and "(β-γ)=2", the master node 21 executes two pods PDb on the worker node 22. Even if people P[2] and P[3] speak at the same time starting from state ST[2,3,1], the resources for the two pods PDb can be used to quickly start up pods PD[2] and PD[3]. Also, for example, in state ST[2,3,2], since "α=2" and "(β-γ)=1", the master node 21 executes one pod PDb on the worker node 22. Since the start of pod PD[4] is not requested in state ST[2,3,2] (therefore, the fast start of pod PD[4] is unnecessary), the number of executed pods PDb in state ST[2,3,2] is sufficient. For example, in state ST[2,3,3], since "α=2" and "(β-γ)=0", the master node 21 does not execute any pod PDb on the worker node 22. This is because if "β=γ", no new interactive pods will be launched.

[0092] If "α≧β", the master node 21 may always set "β=γ". If the upper limit number of balloons α is contracted so as to satisfy "α≧β", each occupant can always smoothly dialogue with the customized dialogue model. That is, for example, if "(α,β)=(2,1)", the master node 21 may set the state of the worker node 22 to the normal state ST[2,1,1] (see FIG. 11). Similarly, for example, if "(α,β)=(2,2)", the master node 21 may set the state of the worker node 22 to the normal state ST[2,2,2] (see FIG. 11). Similarly, for example, if "(α,β)=(3,2)", the master node 21 may set the state of the worker node 22 to the normal state ST[3,2,2] (see FIG. 12). Similarly, for example, if "(α, β)=(3, 3)", the master node 21 may set the state of the worker node 22 to the constant state ST[3, 3, 3] (see FIG. 12).

[0093] A user of the system SYS can also enter into an unlimited contract with the operator of the system SYS. When an unlimited contract is entered into, the balloon upper limit number α is set to infinity (actually, a finite value greater than the maximum number of passengers in the vehicle VV: for example, 255), and the master node 21 may always set “β=γ” regardless of the number of passengers β.

[0094] For the sake of concreteness, the state transition of the worker node 22 was explained under the assumption of the above speech order. However, in reality, the order in which the crew members speak is indeterminate. That is, for example, starting from state ST[1,3,0], it is indeterminate whether the crew member who speaks first to the system SYS will be one of the characters P[1] to P[3]. If, for example, a speech is made by a character P[3] starting from state ST[1,3,0], resource RS1, which was assigned to pod PDb, is handed over to pod PD[3], and pod PD[3] is executed by resource RS1. State ST[1,3,0] enables the rapid activation of the dialogue pod corresponding to the speaker, regardless of whether the crew member who speaks first to the system SYS is one of the characters P[1] to P[3]. The same applies to other similar states.

[0095] Below, several specific operational examples, application techniques, modified techniques, etc. related to the system SYS will be described in multiple embodiments. The matters described above in this embodiment are applied to each of the following embodiments unless otherwise specified and unless there is a contradiction. If there are any matters in each embodiment that contradict the matters described above, the description in each embodiment may take precedence. Furthermore, unless there is a contradiction, matters described in any of the multiple embodiments shown below can also be applied to any other embodiment (i.e., any two or more of the multiple embodiments can be combined).

[0096] <<First Example>> A first embodiment will be described. FIG. 14 shows the flow of operation of the system SYS in the first embodiment. The service management device 20 operates constantly. When the ignition switch of the vehicle VV is operated to start supplying drive power to the in-vehicle device 10 from a power source (not shown) provided in the vehicle VV, the in-vehicle device 10 starts up. When the in-vehicle device 10 starts up, the controller 11 first executes a predetermined initialization process 700. In the initialization process 700, various flags are initialized. Following the initialization process 700, the controller 11 transmits a startup request signal 702 to the master node 21. The startup request signal 702 is a signal requesting the startup of the pod PDcom. Therefore, by transmitting and receiving the startup request signal 702, the controller 11 requests the master node 21 to start up the pod PDcom. Note that a request to start a pod and a request to execute a pod are synonymous.

[0097] When the master node 21 receives the activation request signal 702, the master node 21 performs activation processing 704 for the pod PDcom in accordance with the request of the activation request signal 702. The master node 21 involved in the activation processing 704 allocates resources for the pod PDcom in the worker node 22, and then causes the worker node 22 to execute the pod PDcom. When the activation of the pod PDcom is completed by the activation processing 704, the master node 21 transmits an activation completion signal 706 indicating this to the in-vehicle device 10. The activation completion signal 706 is received by the in-vehicle device 10.

[0098] After receiving the startup completion signal 706, the controller 11 performs a process 708 for detecting the number of passengers β. However, the detection process 708 may be performed at any timing after the initialization process 700. The number of passengers β is detected by the detection process 708. The controller 11 may detect the number of passengers β based on an image captured by the camera CM. Alternatively, the controller 11 may detect the number of passengers β based on an output signal of a seat belt reminder provided in the vehicle VV. Furthermore, information on the upper limit number of balloons α is shared among the devices in the system SYS, and the controller 11 can recognize the upper limit number of balloons α. The upper limit number of balloons α is the upper limit number of balloons associated with person P[1]. If it is known in advance that person P[1] will be riding in the vehicle VV, the controller 11 may read the upper limit number of balloons α corresponding to person P[1] from the recording medium 14 or the registered person table TBL1 in the initialization process 700, etc. (the same applies to other embodiments described below). In cases where the vehicle VV is a shared car, after it is confirmed that the occupants of the vehicle VV include person P[1], the controller 11 may read the balloon upper limit number α corresponding to person P[1] from the recording medium 14 or the registered person table TBL1 (the same applies to other embodiments described later). The controller 11 can confirm that person P[1] is included among the occupants of the vehicle VV through the operator's input operation on the operation unit 16 or personal identification based on images captured by the camera CM. In the first embodiment, it is assumed that the number of passengers β is greater than the balloon upper limit number α (i.e., α<β).

[0099] After the detection process 708 for the number of passengers β, the controller 11 transmits an activation request signal 710 to the master node 21. The activation request signal 710 is a signal requesting the activation of the required number of pods PDb. Therefore, by sending and receiving the activation request signal 710, the controller 11 requests the master node 21 to activate the required number of pods PDb. In the activation request signal 710, the required number of pods PDb is the smaller of the upper limit number of balloons α and the difference (β-γ). Immediately after the execution of the detection process 708, "γ=0", and the activation request signal 710 when "γ=0" requests the activation of α pods PDb.

[0100] When the master node 21 receives the activation request signal 710, the master node 21 performs activation processing 712 for the pod PDb in accordance with the request of the activation request signal 710. The master node 21 involved in the activation processing 712 allocates resources for each pod PDb to the worker node 22, and then causes the worker node 22 to execute each pod PDb. Although the pod PDb requires resources equivalent to those of the pod PD[i], it is extremely lightweight software that does not have any substantial functions. Therefore, once the allocation of resources for each pod PDb is complete, each pod PDb becomes operational in an extremely short time. The state in which activation of α pods PDb is completed by the activation processing 712 corresponds to state ST[1,3,0] if, for example, "(α,β)=(1,3)" (see FIG. 11).

[0101] When the activation of the α pods PDb is completed by the activation process 712, the master node 21 transmits an activation completion signal 714 indicating this to the in-vehicle device 10. The activation completion signal 714 is received by the in-vehicle device 10. After receiving the activation completion signal 714, the controller 11 enters a state in which it can accept an utterance from the person P[i]. In the example of FIG. 14, after receiving the activation completion signal 714, the person P[i] makes an utterance 720. Assume that the utterance 720 is directed to the system SYS. The controller 11 executes a call determination process 722 and a speaker identification process 724 for the utterance 720. The call determination unit F1 (see FIG. 5) determines by the call determination process 722 that the utterance 720 is directed to the system SYS. The speaker identification unit F2 identifies by the speaker identification process 724 that the occupant who made the utterance 720 is the person P[i]. The results of the call determination process 722 and the speaker identification process 724 are input to the dialogue manager F3, and the dialogue manager F3 determines that the person P[i] has made an utterance 720 toward the system SYS.

[0102] When it is determined that person P[i] has made an utterance 720 to the system SYS, the dialogue management unit F3 determines that the dialogue pod corresponding to person P[i] needs to be executed, and transmits an activation request signal 730 to the master node 21. The activation request signal 730 is a signal requesting the activation (execution) of the dialogue pod corresponding to person P[i]. Therefore, by sending and receiving the activation request signal 730, the controller 11 requests the master node 21 to activate (execute) the dialogue pod corresponding to person P[i]. The dialogue pod corresponding to person P[i] is pod PD[i]. In the above-mentioned user registration process, etc., correspondence information between persons P[1] to P[4] and the identification IDs "0001" to "0004" (see FIG. 8) has already been stored in the recording medium 14 of the in-vehicle device 10. Alternatively, the controller 11 can obtain the above correspondence information from the registrant table TBL1 via the master node 21. The controller 11 requests activation (in other words, execution) of the pod PD[i] by using an activation request signal 730 based on the corresponding information.

[0103] When it is determined that the person P[i] has made an utterance 720 to the system SYS, the dialogue manager F3 transmits, in addition to the activation request signal 730, utterance information 732 and a response request signal 734 to the master node 21. The utterance information 732 may include utterance text data indicating the content of the utterance 720. The acoustic signal S of the utterance 720 IN The dialogue management unit F3 can generate utterance text data based on the utterance information 732. However, the utterance information 732 may also include an acoustic signal indicating the content of the utterance 720, in which case the service management device 20 may generate utterance text data based on the acoustic signal in the utterance information 732. The utterance information 732 also includes speaker information that identifies the person who made the utterance 720 (the speaker) as person P[i]. The response request signal 734 is a signal that requests a sentence in response to the utterance 720.

[0104] The master node 21 receives the activation request signal 730, the speech information 732, and the response request signal 734. Upon receiving the activation request signal 730, the master node 21 executes activation processing 740 to activate the pod PD[i] in accordance with the request of the activation request signal 730. In order to activate the pod PD[i], the worker node 22 must secure the resources necessary to execute the pod PD[i]. Here, it is assumed that one or more pods PDb have already been activated at the time of receiving the activation request signal 730, and one of these pods PDb is in an operating state with the resource RS1 allocated to it (see FIG. 10, etc.). However, as described above, the priority of each pod PDb is lower than the priority of the pod PD[i]. Therefore, in the activation processing 740, the master node 21 controls the worker node 22 to release the resource RS1 allocated to the execution of the pod PDb to the resource for executing the pod PD[i]. Subsequently, the master node 21 involved in the activation process 740 controls the worker node 22 to activate the pod PD[i] using the resource RS1. As a result, the worker node 22 deploys the pod PD[i] using the resource RS1, thereby transitioning the state of the pod PD[i] to the running state.

[0105] The time from when the master node 21 receives the activation request signal 730, through when the activation of the pod PD[i] begins, to when the activation of the pod PD[i] is completed, is referred to as the activation wait time. In the first embodiment, the activation wait time is assumed to be sufficiently short. For this reason, in the first embodiment, the pod PD[i] responds to the utterance 720 without relying on a general-purpose dialogue pod (PDcom). When the activation of the pod PD[i] is completed, the master node 21 transmits an activation completion signal 742 to the in-vehicle device 10, indicating that the activation of the pod PD[i] is completed. When the in-vehicle device 10 receives the activation completion signal 742, the controller 11 recognizes that the activation of the pod PD[i] is completed (and therefore that the pod PD[i] is in an operating state), and executes a flag set process 744 to set the activation completion flag FLG[i] to “1.” The startup completion flag FLG[i] is stored in the memory 12 or the recording medium 14, and is set to "0" in the initialization process 700 described above. Therefore, in the flag set process 744, the value of the startup completion flag FLG[i] is changed from "0" to "1." A startup completion flag FLG[i] of "0" indicates that the pod PD[i] has not started up, and a startup completion flag FLG[i] of "1" indicates that the pod PD[i] has started up and is in an operating state.

[0106] On the other hand, when the activation of the pod PD[i] is completed, the master node 21 controls the worker node 22 so that the pod PD[i] performs a response generation process 750. In the response generation process 750, utterance information 732 is input to the pod PD[i], and the pod PD[i] generates a response sentence 752 that responds to the utterance 720 based on the utterance information 732. After the response generation process 750, the master node 21 transmits pod output information 754 including the response sentence 752 to the in-vehicle device 10. When the in-vehicle device 10 receives the pod output information 754, the dialogue management unit F3 performs a response output 756 that transmits the response sentence 752 to the person P[i] using the speaker SP. The pod output information 754 may include text data of the response sentence 752. At this time, the dialogue management unit F3 outputs an acoustic signal S indicating the text data of the response sentence 752. OUTand supplies it to the speaker SP, thereby transmitting the response sentence 752 to the person P[i]. The pot output information 754 may include an audio signal of the response sentence 752. In this case, the dialogue management unit F3 converts the audio signal in the pot output information 754 into an audio signal S OUT The controller 11 may transmit the response sentence 752 to the person P[i] by supplying the response sentence 752 to the speaker SP as a response output 756.

[0107] After that, the state of the in-vehicle device 10 returns to the state immediately after the execution of the detection process 708. Therefore, after the flag set process 744, the controller 11 transmits the activation request signal 710 as needed. Therefore, for example, in the case of "(α, β) = (1, 3)" (see FIG. 10), when the pod PD[1] enters the operating state by the activation process 740 starting from the state ST[1, 3, 0], the state of the worker node 22 reaches the state ST[1, 3, 1] through the second activation process 712. Even when the person P[i] speaks to the system SYS again after the response output 756, a dialogue between the person P[i] and the pod PD[i] takes place in the same manner as the above-described process from the utterance 720 to the response output 756. However, since the pod PD[i] is in the operating state in the state of "FLG[i] = 1," the transmission and reception of the activation request signal 730, the activation process 740, the transmission and reception of the activation completion signal 742, and the flag set process 744 are not executed.

[0108] As described above, when the controller 11 determines that the person P[i] has spoken to the system SYS, it determines that the pod PD[i] corresponding to the person P[i] needs to be executed and requests the master node 21 to activate (execute) the pod PD[i] (730). In response to this request, the master node 21 releases the resources allocated to the execution of the pod PDb to the resources for the execution of the pod PD[i], and then executes the pod PD[i] on the worker node 22 (740; also see FIG. 9). The master node 21 then uses the currently executing pod PD[i], via the controller 11, to realize a dialogue with the person P[i] (720, 732, 750, 754, 756) using the microphone MC and speaker SP. These operations are performed for each occupant of the vehicle VV. This method allows a dialogue pod appropriate for each occupant to be quickly activated when needed (subject to the constraint of the upper limit number of balloons α described above).

[0109] <<Second Example>> A second embodiment will now be described. Figures 15 and 16 show the flow of operation of the system SYS in the second embodiment. In the second embodiment, the flow of processing up to the execution of the startup process 740 and the contents of the startup process 740 are the same as those in the first embodiment. However, in the second embodiment, it is assumed that the startup wait time will be fairly long, and therefore a general-purpose interactive pod (PDcom) is used until the startup of the pod PD[i] is complete. As described above, the startup wait time refers to the time from when the master node 21 receives the startup request signal 730, through the start of startup of the pod PD[i], until the startup of the pod PD[i] is completed.

[0110] Specifically, when the master node 21 receives the activation request signal 730, the master node 21 executes activation processing 740 for the pod PD[i]. In the activation processing 740, the master node 21 controls the worker node 22 to transfer the resource RS1 allocated to the execution of the pod PDb to the resource for executing the pod PD[i]. Thereafter, the master node 21 involved in the activation processing 740 deploys the pod PD[i] in the database 23 using the resource RS1 in the worker node 22, thereby activating the pod PD[i] on the worker node 22. When the activation of the pod PD[i] is completed, the pod PD[i] reaches an operating state (a state in which it is possible to interact with the person P[i]).

[0111] The master node 21 according to the second embodiment controls the worker node 22 so that the pod PDcom performs a response generation process 770 after the start of the startup process 740 and before the startup of the pod PD[i] is completed. In the response generation process 770, utterance information 732 is input to the pod PDcom, and the pod PDcom generates a response sentence 772 that responds to the utterance 720 based on the utterance information 732. After the response generation process 770, the master node 21 transmits pod output information 774 including the response sentence 772 to the in-vehicle device 10. When the in-vehicle device 10 receives the pod output information 774, the dialogue manager F3 performs a response output 776 that transmits the response sentence 772 to the person P[i] using the speaker SP. The transmission and reception of the pod output information 774 and the response output 776 are performed before the transmission and reception of a startup completion signal 782, which will be described later. The pod output information 774 may include text data of the response sentence 772. At this time, the dialogue management unit F3 generates an audio signal S indicating the text data of the response sentence 772. OUT and supplies it to the speaker SP, thereby transmitting the response sentence 772 to the person P[i]. The pot output information 774 may include an audio signal of the response sentence 772. In this case, the dialogue management unit F3 converts the audio signal in the pot output information 774 into an audio signal S OUT The controller 11 may transmit the response sentence 772 to the person P[i] by supplying the response sentence 772 to the speaker SP as a response output 776.

[0112] Thereafter, if person P[i] speaks again to system SYS before pod PD[i] has completed startup, a dialogue between person P[i] and pod PDcom will take place in the same manner as the above-mentioned utterance 720 to response output 776.

[0113] After the interaction between the person P[i] and the pod PDcom, when the startup of the pod PD[i] by the startup process 740 is completed, the master node 21 transmits a startup completion signal 782 to the in-vehicle device 10, indicating that the startup of the pod PD[i] is completed. When the in-vehicle device 10 receives the startup completion signal 782, the controller 11 recognizes that the startup of the pod PD[i] is completed (and therefore that the pod PD[i] is in an operating state), and executes a flag set process 784 to set the startup completion flag FLG[i] to "1." As described in the first embodiment, the startup completion flag FLG[i] is stored in the memory 12 or the recording medium 14, and the startup completion flag FLG[i] is set to "0" in the initialization process 700 described above.

[0114] After the flag set process 784, the controller 11 transmits a start-up request signal 790 as needed. The start-up request signal 790, like the start-up request signal 710, is a signal requesting the start-up of the required number of pods PDb. Therefore, by transmitting and receiving the start-up request signal 790, the controller 11 requests the master node 21 to start up the required number of pods PDb. In the start-up request signal 790, the required number of pods PDb is the smaller of the upper limit number of balloons α and the difference (β-γ). If "β=γ", the start-up request signal 790 is not transmitted or received, but the following explanation will continue assuming a situation in which the start-up request signal 790 is transmitted and received.

[0115] When the master node 21 receives the activation request signal 790, the master node 21 performs activation processing 792 for the pod PDb in accordance with the request of the activation request signal 790. The master node 21 involved in the activation processing 792 allocates resources for the pod PDb to the worker node 22 and then causes the worker node 22 to execute the pod PDb. Therefore, when "(α, β) = (1, 3)" (see FIG. 10 ), if the pod PD[1] enters an operating state by the activation processing 740 starting from state ST[1, 3, 0], the state of the worker node 22 reaches state ST[1, 3, 1] through the subsequent activation processing 792. When the activation of the pod PDb is completed by the activation processing 792, the master node 21 transmits an activation completion signal 794 indicating this to the in-vehicle device 10. The activation completion signal 794 is received by the in-vehicle device 10.

[0116] FIG. 16 shows the flow of operations after the transmission and reception of the startup completion signal 794. After the transmission and reception of the startup completion signal 794, person P[i] makes an utterance 820 in the state of "FLG[i]=1." Assume that the utterance 820 is directed to the system SYS. The controller 11 executes a call determination process 822 and a speaker identification process 824 for the utterance 820. The call determination unit F1 (see FIG. 5) determines through the call determination process 822 that the utterance 820 is directed to the system SYS. The speaker identification unit F2 identifies through the speaker identification process 824 that the occupant who made the utterance 820 is person P[i]. The results of the call determination process 822 and the speaker identification process 824 are input to the dialogue management unit F3, and the dialogue management unit F3 determines that person P[i] made the utterance 820 directed to the system SYS.

[0117] When it is determined that the person P[i] has made an utterance 820 to the system SYS, the dialogue management unit F3 transmits utterance information 832 and a response request signal 834 to the master node 21. At the time when it is determined that the utterance 820 has been made to the system SYS, "FLG[i]=1" is set, and the controller 11 recognizes that the pod PD[i] is in an operating state. Therefore, the controller 11 does not transmit a signal requesting activation of the pod PD[i] in response to the utterance 820. The utterance information 832 may include utterance text data indicating the content of the utterance 820. The acoustic signal S of the utterance 820 IN The dialogue management unit F3 can generate utterance text data based on the utterance information 832. However, the utterance information 832 may also include an acoustic signal indicating the content of the utterance 820, in which case the service management device 20 may generate utterance text data based on the acoustic signal in the utterance information 832. The utterance information 832 also includes speaker information that identifies the person who made the utterance 820 (the speaker) as person P[i]. The response request signal 834 is a signal that requests a sentence in response to the utterance 820.

[0118] The master node 21 receives the utterance information 832 and the response request signal 834. The master node 21 controls the worker node 22 so that the pod PD[i] performs a response generation process 850. In the response generation process 850, the utterance information 832 is input to the pod PD[i], and the pod PD[i] generates a response sentence 852 that responds to the utterance 820 based on the utterance information 832. After the response generation process 850, the master node 21 transmits pod output information 854 including the response sentence 852 to the in-vehicle device 10. When the in-vehicle device 10 receives the pod output information 854, the dialogue management unit F3 performs a response output 856 that transmits the response sentence 852 to the person P[i] using the speaker SP. The pod output information 854 may include text data of the response sentence 852. At this time, the dialogue management unit F3 outputs an acoustic signal S indicating the text data of the response sentence 852. OUTand supplies it to the speaker SP, thereby transmitting the response sentence 852 to the person P[i]. The pot output information 854 may include an audio signal of the response sentence 852. In this case, the dialogue management unit F3 converts the audio signal in the pot output information 854 into an audio signal S OUT The controller 11 may transmit the response sentence 852 to the person P[i] by supplying the response sentence 852 to the speaker SP as a response output 856.

[0119] Thereafter, when the person P[i] speaks again to the system SYS, a dialogue between the person P[i] and the pod PD[i] is carried out in the same manner as the above-mentioned process from the utterance 820 to the response output 856.

[0120] However, if "FLG[i]=1", after the response output 856, the controller 11 performs a disruption determination process 860. In the disruption determination process 860 executed when "FLG[i]=1", the controller 11 measures the dialogue downtime Tst[i], and when the dialogue downtime Tst[i] reaches a reference time Tref, it determines to stop the execution of the pod PD[i]. The reference time Tref is a predetermined fixed time (for example, several tens of seconds to several minutes).

[0121] The dialogue pause time Tst[i] is the time during which the dialogue between person P[i] and pod PD[i] is paused. At the end of the response output 856, the dialogue pause time Tst[i] is zero. In the pause determination process 860, the controller 11 measures the elapsed time from the end of the response output 856 as the dialogue pause time Tst[i]. If the controller 11 determines that person P[i] has spoken to the system SYS before the dialogue pause time Tst[i] reaches the reference time Tref, the controller 11 terminates the pause determination process 860 and performs the above-described operations corresponding to the utterance of person P[i]. When the controller 11 terminates the pause determination process 860, it initializes the dialogue pause time Tst[i] to zero. If the operations from the utterance 820 to the response output 856 are repeated, the pause determination process 860 is performed each time the response output 856 is performed.

[0122] If it is determined in the disruption determination process 860 that "Tst[i]≧Tref" is satisfied and therefore the execution of the pod PD[i] should be stopped, the controller 11 transmits a stop request signal 862 to the master node 21. The stop request signal 862 is a signal requesting that the execution of the pod PD[i] be stopped. When the stop request signal 862 is received by the master node 21, the master node 21 performs a stop process 864 for the pod PD[i]. In the stop process 864, the master node 21 controls the worker node 22 so that the execution of the pod PD[i] in an operating state is stopped. As a result, the execution of the pod PD[i] in the worker node 22 is stopped, and the resources allocated to the pod PD[i] are released.

[0123] When the execution of the pod PD[i] has been stopped, a stop completion signal 866 indicating this is transmitted from the master node 21 to the in-vehicle device 10. When the stop completion signal 866 is received by the in-vehicle device 10, the controller 11 executes a flag reset process 868 that sets the startup completion flag FLG[i] to "0." The state of the in-vehicle device 10 then returns to the state immediately after the execution of the detection process 708 (see FIG. 15). Therefore, after the flag reset process 868, the controller 11 transmits a startup request signal 710 as needed. Therefore, for example, when "(α, β) = (1, 3)" (see FIG. 10), if the pod PD[3] enters the operating state by the startup process 740 starting from the state ST[1, 3, 2], the state of the worker node 22 reaches the state ST[1, 3, 3]. After that, when the stop process 864 is executed and the execution of the pod PD[3] is stopped, the state returns to the state ST[1, 3, 2] by the subsequent startup process 712.

[0124] As described above, the pod PDcom is set to an operating state in advance. The master node 21 starts the activation of the pod PD[i] upon receiving the activation request signal 730, but it takes a considerable amount of time for the activation of the pod PD[i] to be completed. Therefore, before the activation of the pod PD[i] is completed, the system SYS (master node 21) realizes a conversation with the person P[i] using the microphone MC and speaker SP via the controller 11 using the running pod PDcom (720, 732, 770, 774, 776). After the activation of the pod PD[i] is completed, the system SYS (master node 21) realizes a conversation with the person P[i] using the microphone MC and speaker SP via the controller 11 using the running pod PD[i] (820, 832, 850, 854, 856). This method enables a dialogue between the speaker and the dialogue model (PDcom) without making the speaker wait, even if it takes time for the pod PD[i] to complete its startup. Once the pod PD[i] has completed its startup, a dialogue using a dialogue model that suits the speaker is possible.

[0125] In addition, by implementing a function to stop the execution of pod PD[i] when dialogue between person P[i] and pod PD[i] ceases for a certain period of time, unnecessary consumption of resources can be reduced.

[0126] <<Third Example>> A third embodiment will now be described. Figures 17 and 18 show an operational flowchart of the controller 11 according to the third embodiment. The operational flowcharts of Figures 17 and 18 correspond to the operational flow of the second embodiment. Therefore, the operation of the controller 11 shown in Figures 17 and 18 will be described while referring to the symbols shown in the second embodiment as appropriate (also see Figures 15 and 16 as appropriate).

[0127] When the ignition switch of the vehicle VV is operated to start supplying drive power to the in-vehicle device 10 from a power source (not shown) provided in the vehicle VV, the in-vehicle device 10 starts up. When the in-vehicle device 10 starts up, first, in step S11, the controller 11 executes a predetermined initialization process 700. In the initialization process 700, initialization of each flag is performed. In the initialization process 700, all startup completion flags are set to "0". In step S12 following step S11, the controller 11 transmits a startup request signal 702 of the pod PDcom to the master node 21, and then in step S13, the controller 11 waits to receive a startup completion signal 706 from the master node 21. When the startup completion signal 706 is received by the in-vehicle device 10 (Yes in step S13), the process proceeds to step S14. If the startup completion signal 706 is not received even after a predetermined timeout period has elapsed after the startup request signal 702 has been transmitted, the controller 11 performs a predetermined error process (such as retransmitting the startup request signal 702).

[0128] In step S14, the controller 11 performs detection process 708 for the number of passengers β. The number of passengers β is detected by detection process 708. The method for detecting the number of passengers β is as described above. In step S15 following step S14, the controller 11 determines whether the balloon upper limit number α is equal to or greater than the number of passengers β. If "α≧β" holds (Yes in step S15), the process proceeds to step S16, and if "α<β" holds (No in step S15), the process proceeds to step S17.

[0129] In step S16, the controller 11 requests the master node 21 to activate the corresponding dialogue pods for the number of passengers β. For example, if "β=3" and persons P[1] to P[3] are on board the vehicle VV, the controller 11 in step S16 transmits to the master node 21 an activation request signal requesting activation of pod PD[1], an activation request signal requesting activation of pod PD[2], and an activation request signal requesting activation of pod PD[3]. When the master node 21 receives these three activation request signals, the master node 21 executes processing to activate pods PD[1] to PD[3] in the worker node 22, and after activation is complete, pods PD[1] to PD[3] enter an operating state. Note that in the second embodiment, a situation where "α<β" is assumed is assumed, and therefore the operation corresponding to step S16 is not shown in FIGS. 15 and 16. After step S16, the process proceeds to step S19.

[0130] In step S17, the controller 11 determines whether activation of the dialogue pods corresponding to all occupants has been completed. Only when the activation completion flags FLG[1] to FLG[β] are all "1," it is determined that activation of the dialogue pods corresponding to all occupants has been completed (Yes in step S17), and the process proceeds from step S17 to step S21. If any one of the activation completion flags FLG[1] to FLG[β] is set to "0" (No in step S17), the process proceeds from step S17 to step S18.

[0131] In step S18, the controller 11 transmits to the master node 21 a start-up request signal requesting the activation of the required number of pods PDb. An example of the start-up request signal transmitted in step S18 is the start-up request signal 710 or 790 in FIG. 15. As described in the first or second embodiment, the required number of pods PDb is the smaller of the upper limit number of balloons α and the difference (β-γ). If the controller 11 has already requested the activation of the required number of pods PDb and the required number of pods PDb are in operation on the service management device 20 side, the transmission process of step S18 is not performed, or even if it is performed, the start-up request signal is invalidated on the master node 21 side. After step S18, the process proceeds to step S19.

[0132] In step S19, the controller 11 checks whether the in-vehicle device 10 has received a startup completion signal, which is a signal transmitted from the master node 21 and indicates that startup of any of the pods PD[1] to PD[β] has been completed. The startup completion signal 782 in Fig. 15 is an example of a signal to be received in step S19. If the startup completion signal is received by the in-vehicle device 10 in step S19 (Yes in step S19), the process proceeds to step S20; otherwise (No in step S19), the process proceeds to step S21.

[0133] In step S20, the controller 11 performs a flag setting process to set the startup completion flag corresponding to the received startup completion signal to "1." Therefore, if the reception of the startup completion signal indicating that the startup of the pod PD[1] has been completed is confirmed in step S19, the controller 11 in step S20 sets the startup completion flag FLG[1] to "1." Similarly, if the reception of the startup completion signal indicating that the startup of the pod PD[2] has been completed is confirmed in step S19, the controller 11 in step S20 sets the startup completion flag FLG[2] to "1." The same applies to pod PD[3], etc. The flag setting process 784 in FIG. 15 is an example of the flag setting process in step S20. After step S20, the process proceeds to step S21.

[0134] In step S21, the controller 11 executes a call determination process to determine whether any of the occupants has spoken to the system SYS. The call determination process 722 in Fig. 15 or the call determination process 822 in Fig. 16 are examples of the call determination process in step S21. If it is determined that any of the occupants has spoken to the system SYS (Yes in step S21), the process proceeds to step S22; otherwise (No in step S21), the process proceeds to step S32.

[0135] In step S22, the controller 11 performs speaker identification processing to identify the individual occupant who has spoken to the system SYS. Here, it is assumed that one or more of the individuals P[1] to P[4] are occupants of the vehicle VV, and therefore, through the individual identification, it is determined which of the individuals P[1] to P[4] the occupant who has spoken is. The speaker identification processing 724 in FIG. 15 or the speaker identification processing 824 in FIG. 16 are examples of the speaker identification processing in step S22. Hereinafter, it is assumed that the individual who has spoken to the system SYS is determined to be individual P[i] through the individual identification in step S22, and individual P[i] may be referred to as speaker P[i]. After step S22, the process proceeds to step S23.

[0136] In step S23, the controller 11 checks whether the dialogue pod (i.e., pod PD[i]) corresponding to the speaker P[i] has been activated. This check is equivalent to checking the value of the activation completion flag FLG[i]. If "FLG[i]=1", it is determined that the dialogue pod (i.e., pod PD[i]) corresponding to the speaker P[i] has been activated (Yes in step S23), and the process proceeds to step S28. If "FLG[i]=0", it is determined that the dialogue pod (i.e., pod PD[i]) corresponding to the speaker P[i] has not been activated (No in step S23), and the process proceeds to step S24.

[0137] 15, and proceeds through steps S21 to S23 to step S24. In step S24, the controller 11 transmits to the master node 21 an activation request signal 730 requesting activation of the dialogue pod (i.e., pod PD[i]) corresponding to the speaker P[i]. In step S25 following step S24, the controller 11 transmits to the master node 21 utterance information 732 including the content of the utterance 720 of the speaker P[i], and a response request signal 734. However, steps S24 and S25 may be performed in any order. After steps S24 and S25, the process proceeds to step S26.

[0138] In step S26, the controller 11 waits for reception of the pod output information 774 from the master node 21. When the in-vehicle device 10 receives the pod output information 774 (Yes in step S26), the process proceeds to step S27. If the pod output information 774 is not received even after a predetermined timeout period has elapsed since the transmission of the utterance information 732 and the response request signal 734, the controller 11 performs predetermined error processing (such as retransmission of the utterance information 732 and the response request signal 73). The pod output information 774 includes a response sentence 772 corresponding to the content of the utterance 720 (see FIG. 15). In step S27, the controller 11 uses the speaker SP to perform a response output 776, which transmits the response sentence 772 included in the pod output information 774 to the speaker P[i]. In the response output 776, the controller 11 may display the text data of the response sentence 772 on the display unit 15. After step S27, the process returns to step S17.

[0139] 16, and proceeds through steps S21 to S23 to step S28. In step S28, the controller 11 transmits utterance information 832 including the content of the utterance 820 of the speaker P[i] and a response request signal 834 to the master node 21. After step S28, the process proceeds to step S29.

[0140] In step S29, the controller 11 waits for reception of the pod output information 854 from the master node 21. When the in-vehicle device 10 receives the pod output information 854 (Yes in step S29), the process proceeds to step S30. Note that if the pod output information 854 is not received even after a predetermined timeout period has elapsed after transmitting the utterance information 832 and the response request signal 834, the controller 11 performs predetermined error processing (such as retransmission processing of the utterance information 832 and the response request signal 83). The pod output information 854 includes a response sentence 852 corresponding to the content of the utterance 820 (see FIG. 16). In step S30, the controller 11 uses the speaker SP to perform a response output 856, which transmits the response sentence 852 included in the pod output information 854 to the speaker P[i]. In the response output 856, the controller 11 may display the text data of the response sentence 852 on the display unit 15. After step S30, the process proceeds to step S31.

[0141] In step S31, the controller 11 starts measuring the dialogue pause time Tst[i] corresponding to the speaker P[i]. The dialogue pause time Tst[i] is the time during which the dialogue between the person P[i] who was the speaker P[i] of the content of the utterance 820 and the pod PD[i] has stopped. The controller 11 assigns zero to the dialogue pause time Tst[i] at the end of the response output 856 in step S30, and measures the elapsed time from the end of the response output 856 as the dialogue pause time Tst[i]. Once measurement of the dialogue pause time Tst[i] has started, the process returns to step S17. A dialogue pause time is defined for each of the persons P[1] to P[β] aboard the vehicle VV, and the dialogue pause time is measured for each speaker. That is, when a response output is made in step S30 in response to person P[1] speaking to the system SYS, measurement of the dialogue pause time Tst[1] between person P[1] and pot PD[1] begins in step S31. Similarly, when a response output is made in step S30 in response to person P[2] speaking to the system SYS, measurement of the dialogue pause time Tst[2] between person P[2] and pot PD[2] begins in step S31. The same applies to person P[3], etc. Note that each dialogue pause time is initialized to zero in the initialization process 700 in step S11, and is maintained at zero unless step S31 is reached.

[0142] In step S32, the controller 11 determines whether any of the dialogue stop times Tst[1] to Tst[β] has reached the reference time Tref. If none of the dialogue stop times Tst[1] to Tst[β] has reached the reference time Tref (No in step S32), the process returns to step S17 without proceeding to step S33. If any of the dialogue stop times Tst[1] to Tst[β] has reached the reference time Tref (Yes in step S32), the process proceeds to step S33. Steps S31 and S32 form the disruption determination process 860 (FIG. 16) shown in the second embodiment.

[0143] The processing in steps S33 to S35 will be described assuming that the process proceeds from step S32 to step S33 when the dialogue stop time Tst[i] reaches the reference time Tref. In step S33, the controller 11 determines to stop the execution of the pod PD[i] and transmits a stop request signal 862 requesting the pod PD[i] to be stopped to the master node 21. That is, the controller 11 transmits to the master node 21 the stop request signal 862 for the dialogue pod (PD[i]) corresponding to the dialogue stop time Tst[i] that has reached the reference time Tref. In step S34 following step S33, the controller 11 waits for reception of a stop completion signal 866 from the master node 21. When the stop completion signal 866 is received by the in-vehicle device 10 (Yes in step S34), the process proceeds to step S35. Note that if the stop completion signal 866 is not received even after a predetermined time-out period has elapsed after transmitting the stop request signal 862, the controller 11 performs a predetermined error process (such as retransmitting the stop completion signal 866).

[0144] In step S35, the controller 11 performs a flag reset process to set the startup completion flag corresponding to the received stop completion signal 866 to "0." Here, since the received stop completion signal 866 indicates that the execution of the pod PD[i] has been stopped, the startup completion flag corresponding to the stop completion signal 866 is the startup completion flag FLG[i]. The reset flag process 868 in Figure 16 is an example of the flag reset process of step S35. After step S35, the process returns to step S17.

[0145] 19 and 20 show an operation flowchart of the master node 21 according to the third embodiment. The operation flowcharts of FIGS. 19 and 20 correspond to the flow of operation of the second embodiment. For this reason, the operation of the master node 21 shown in FIGS. 19 and 20 will be explained while appropriately referring to the symbols used in the second embodiment (also see FIGS. 15 and 16 as appropriate). The operation mainly performed by the master node 21 can be understood as the operation of the processor provided in the master node 21. As already mentioned, the service management device 20 operates all the time, but in relation to the in-vehicle device 10, the master node 21 first waits in step S51 to receive a startup request signal 720 from the pod PDcom. When the startup request signal 720 is received (Yes in step S51), the process proceeds to step S52.

[0146] In step S52, the master node 21 performs a startup process 704 for the pod PDcom. When the startup of the pod PDcom is completed by the startup process 704, in step S53 the master node 21 transmits a startup completion signal 706 indicating this to the in-vehicle device 10. Then, the process proceeds to step S54.

[0147] In step S54, the master node 21 checks whether a startup request signal for the pod PDb has been received from the in-vehicle device 10 (controller 11). If a startup request signal for the pod PDb has been received (Yes in step S54), the process proceeds to step S55. If a startup request signal for the pod PDb has not been received (No in step S54), the process proceeds to step S57. The startup request signal 710 or 790 in FIG. 15 is an example of the startup request signal related to step S54. In step S55, the master node 21 performs startup processing for the pod PDb. The startup processing 712 or 792 in FIG. 15 is an example of the startup processing related to step S55. When the startup of the pod PDb is completed in the startup processing of step S55, the master node 21 transmits a startup completion signal for the pod PDb to the in-vehicle device 10 in step S56. The startup completion signal 714 or 794 in FIG. 15 is an example of the startup completion signal related to step S56. After step S56, the process proceeds to step S57.

[0148] In step S57, the master node 21 checks whether it has received a startup request signal for the pod PD[i] from the in-vehicle device 10 (controller 11). In the example of FIG. 15, the startup request signal whose reception is confirmed in step S57 is the startup request signal 730. In the following, it is assumed that the startup request signal whose reception is confirmed in step S57 is the startup request signal 730. If the startup request signal 730 has been received (Yes in step S57), the process proceeds to step S58; otherwise (No in step S57), the process proceeds to step S59.

[0149] In step S58, the master node 21 performs startup processing 740 for the pod PD[i] in response to the request of the startup request signal 730. The startup processing 740 starts the startup of the pod PD[i], but it takes a considerable amount of time (the startup waiting time described above) until the startup of the pod PD[i] is complete. After the startup of the pod PD[i] is started in the startup processing 740, the process proceeds to step S59 without waiting for the startup of the pod PD[i] to be completed.

[0150] In step S59, the master node 21 checks whether it has received the speech information of person P[i] and a response request signal from the in-vehicle device 10 (controller 11). The speech information 732 in Fig. 15 or the speech information 832 in Fig. 16 is an example of the speech information of person P[i] related to step S59. The response request signal 734 in Fig. 15 or the response request signal 834 in Fig. 16 is an example of the response request signal related to step S59. If the speech information and the response request signal have been received (Yes in step S59), the process proceeds to step S60; otherwise (No in step S59), the process proceeds to step S65.

[0151] In step S60, the master node 21 checks whether the startup of the pod PD[i] is complete. If the startup of the pod PD[i] is complete (Yes in step S60), the process proceeds to step S63. If the startup of the pod PD[i] is not complete (No in step S60), the process proceeds to step S61.

[0152] The processes of steps S61 and S62 will be described assuming that the utterance information and response request signal received in step S59 are the utterance information 732 and the response request signal 734 (see FIG. 15). In step S61, the master node 21 controls the worker node 22 so that the pod PDcom performs a response generation process 770. In the response generation process 770, utterance information 732 indicating the content of the utterance 720 is input to the pod PDcom, and the pod PDcom generates a response sentence 772 responding to the utterance 720 based on the utterance information 732 (see FIG. 15). In step S62 following step S61, the master node 21 transmits pod output information 774 including the response sentence 772 to the in-vehicle device 10. After step S62, the process proceeds to step S65.

[0153] The processes of steps S63 and S64 will be described assuming that the utterance information and response request signal received in step S59 are utterance information 832 and response request signal 834 (see FIG. 16). In step S63, the master node 21 controls the worker node 22 so that the pod PD[i] performs a response generation process 850. In the response generation process 850, utterance information 832 indicating the content of the utterance 820 is input to the pod PD[i], and the pod PD[i] generates a response sentence 852 responding to the utterance 820 based on the utterance information 832 (see FIG. 16). In step S64 following step S63, the master node 21 transmits pod output information 854 including the response sentence 852 to the in-vehicle device 10. After step S64, the process proceeds to step S65.

[0154] In step S65, the master node 21 checks whether the startup of the pod PD[i] has been completed in the worker node 22 and whether the pod PD[i] is in an operating state. In addition, the master node 21 checks whether the startup completion signal 782 indicating that the startup of the pod PD[i] has been completed has not been transmitted to the in-vehicle device 10. If the startup of the pod PD[i] has been completed and the startup completion signal 782 has not been transmitted to the in-vehicle device 10 (Yes in step S65), the process proceeds to step S66; otherwise (No in step S65), the process proceeds to step S67. In step S66, the master node 21 transmits the startup completion signal 782 to the in-vehicle device 10. After step S66, the process proceeds to step S67.

[0155] In step S67, the master node 21 checks whether it has received a stop request signal 862 for the pod PD[i] from the in-vehicle device 10 (controller 11). If it has received the stop request signal 862 (Yes in step S67), it proceeds to step S68, and if it has not received the stop request signal 862 (No in step S67), it returns to step S54.

[0156] In step S68, the master node 21 performs a stop process 864 for the pod PD[i]. In the stop process 864, the master node 21 controls the worker node 22 to stop the execution of the pod PD[i] that is in an operating state. As a result, the execution of the pod PD[i] is stopped in the worker node 22, and the resources allocated to the pod PD[i] are released. When the stop of the execution of the pod PD[i] is completed, in step S69, the master node 21 transmits a stop completion signal 866 indicating that the execution of the pod PD[i] has stopped to the in-vehicle device 10. After step S69, the process returns to step S54 (see FIG. 19 ).

[0157] <<Fourth Example>> A fourth embodiment will be described. In the fourth embodiment, modified techniques, applied techniques, supplementary matters, etc. related to the system SYS will be described.

[0158] A person not registered in the registered person table TBL1 (hereinafter referred to as an unregistered person) may board the vehicle VV and speak to the system SYS. Even if a person registered in the registered person table TBL1 is the speaker, the individual may not be able to be identified. When the speaker is an unregistered person or when the individual cannot be identified, the speaker identification unit F2 communicates to the dialogue management unit F3 that the speaker is unknown. In this case, the controller 11 transmits utterance information, including the content of the speaker's utterance but not including speaker information identifying the speaker, to the master node 21 along with a response request signal requesting a sentence in response to the speaker's utterance. The master node 21 then controls the worker node 22 so that the pod PDcom generates a sentence in response to the speaker's utterance. As a result, a dialogue is conducted between the speaker (such as an unregistered person) and the pod PDcom.

[0159] For the sake of concreteness, the configuration and operation of the system SYS have been described focusing on one vehicle VV, but in reality, the system SYS may be operated in relation to multiple vehicles. In this case, it can be considered that the system SYS for each vehicle is constructed by multiple on-board devices in the multiple vehicles and the service management device 20.

[0160] In the system SYS, when the second software is being executed on the worker node 22 and it is determined that the first software corresponding to a given target person needs to be executed, the master node 21 is requested to start the first software corresponding to the target person. In response to the request, the master node 21 releases the resources allocated to the execution of the second software to resources for executing the first software corresponding to the target person, and then executes the first software corresponding to the target person on the worker node 22. In this embodiment, pod PD[i] is an example of the first software, and pod PDb is an example of the second software. Pod PD[i] is software used for interacting with the corresponding person, but the function of the first software is arbitrary. The first software is arbitrary as long as it is software associated with the corresponding person.

[0161] The system SYS and the present invention embodied in the system SYS can also be applied to any applications other than in-vehicle applications.

[0162] A program that causes a computer device to execute any of the methods described in each embodiment of the present invention, and a non-volatile recording medium on which the program is recorded, are included within the scope of the embodiments of the present invention. A program that causes a computer (computer device) to execute any of the methods described in the embodiments of the present invention may be a subprogram incorporated into any main program or called by any main program. The in-vehicle device 10, the master node 21, and the worker node 22 each include a computer capable of executing any of the programs. The arithmetic processing units provided in each of the in-vehicle device 10, the master node 21, and the worker node 22 may be considered to be computers. Any of the processes in the embodiments of the present invention may be realized by hardware such as a semiconductor integrated circuit, software corresponding to the program, or a combination of hardware and software.

[0163] The embodiments of the present invention can be modified in various ways as appropriate within the scope of the technical ideas set forth in the claims. The above-described embodiments are merely examples of the present invention, and the meanings of the terms of the present invention and each constituent element are not limited to those described in the above-described embodiments. The specific numerical values ​​shown in the above description are merely examples, and as a matter of course, they can be changed to various numerical values. [Explanation of symbols]

[0164] SYS Service provision system VV vehicle MC Microphone SP speaker Commercial camera P[i] person NET communication network 10 Onboard equipment 11 Controller 12 Memory 13 Communications Department 14 Recording media 15 Display 16 Control section 20 Service Management Device 21 Master Nodes 22 worker nodes 23 Pod Database 24 Service Management Database PD[i] Pod (Dialogue Pod) PDcom Pod (Dialogue Pod) PDb Pod (Balloon Pod) F1 Call Judgment Unit F2 Speaker identification unit F3 Dialogue Management Department TBL1 Registered User Table

Claims

1. a vehicle-side device having a first controller and disposed in a vehicle; a database that stores a plurality of first software programs and a plurality of second software programs that are individually associated with a plurality of persons who board the vehicle; A service providing system comprising: a second controller; and a service management device having a worker node that executes software in the database under the control of the second controller, the second software is executed on the worker node in response to a request from the first controller to the second controller to execute the second software; Thereafter, when the first controller determines that it is necessary to execute the first software corresponding to any one of the plurality of persons, the first controller requests the second controller to start the first software corresponding to the target person, and the second controller executes the first software corresponding to the target person on the worker node after releasing the resources allocated to the execution of the second software to resources for the execution of the first software corresponding to the target person. ,service delivery system.

2. During a period in which the first software is executed for each of the plurality of people, the second software is not executed on the worker node. The service providing system according to claim 1 .

3. During a period different from the period, the second software is executed on the worker nodes by the smaller number of the predetermined upper limit number and the number obtained by subtracting the total number of the first software being executed from the total number of the plurality of people. The service providing system according to claim 2 .

4. A microphone and a speaker are arranged in the vehicle, Each first software has an interaction model used for interaction with a corresponding person; When the first controller determines that the target person has spoken to the service providing system, it determines that the first software corresponding to the target person needs to be executed and requests the second controller to start the first software corresponding to the target person. In response to the request, the second controller surrenders the resources allocated to the execution of the second software to resources for executing the first software corresponding to the target person, and then executes the first software corresponding to the target person on the worker node, and realizes a conversation with the target person using the microphone and the speaker via the first controller using the first software that is being executed.

4. The service providing system according to claim 1.

5. The database stores third software common to the plurality of persons, the third software is software for realizing a dialogue with any one of the plurality of people, The third software is executed on the worker node; When the first controller determines that the target person has spoken to the service providing system, it determines that the first software corresponding to the target person needs to be executed and requests the second controller to start the first software corresponding to the target person. In response to the request, the second controller starts the start of the first software corresponding to the target person through a process of transferring resources allocated to the execution of the second software to resources for executing the first software corresponding to the target person. Before the start of the first software corresponding to the target person is completed, the third software being executed realizes a conversation with the target person using the microphone and the speaker via the first controller, and after the start of the first software corresponding to the target person is completed, the first software corresponding to the target person realizes a conversation with the target person using the microphone and the speaker via the first controller. The service providing system according to claim 4 .

6. After the activation of the first software corresponding to the target person is completed, when the dialogue between the target person and the first software corresponding to the target person ceases for a certain period of time, the first controller requests the second controller to stop the execution of the first software corresponding to the target person, thereby stopping the execution of the first software corresponding to the target person. The service providing system according to claim 5 .

7. the first software is a first pod having one or more containers each including an application program; the second software is a second pod having one or more other containers including other application programs; A higher priority is set for the first pod than for the second pod, and when activation of the first software is requested, the second controller allocates resources of the worker node to the first pod with priority over the second pod.

4. The service providing system according to claim 1.

8. The amount of resources allocated to the execution of the second software is equal to or greater than the amount of resources allocated to the execution of the first software.

4. The service providing system according to claim 1.

9. A service providing method used in a service providing system including a vehicle-side device disposed in a vehicle, a database that stores a plurality of first software programs and second software programs that are individually associated with a plurality of persons riding in the vehicle, and a service management device having a worker node, After the second software is executed on the worker node, if the vehicle-side device determines that it is necessary to execute the first software corresponding to any one of the plurality of persons, the vehicle-side device surrenders the resources allocated to the execution of the second software to resources for the execution of the first software corresponding to the target person, and then executes the first software corresponding to the target person on the worker node. ,Service delivery methods.

10. a vehicle-side device having a first controller and disposed in a vehicle, the vehicle-side device having a second controller and a worker node that executes software in a database under the control of the second controller, and bidirectionally communicating with a service management device; the database holds a plurality of first software programs and a plurality of second software programs each associated with a plurality of persons riding in the vehicle; the first controller requests the second controller to execute the second software, thereby causing the worker node to execute the second software; Thereafter, when the first controller determines that it is necessary to execute the first software corresponding to any one of the plurality of persons, it requests the second controller to execute the first software corresponding to the target person, thereby causing the second controller to execute the first software corresponding to the target person on the worker node after yielding the resources allocated to the execution of the second software to resources for the execution of the first software corresponding to the target person. , vehicle side device.

Images