JP7147167B2 - Control program, control method and information processing device - Google Patents

Description

The present invention relates to a control program, control method, and information processing apparatus.

Prototypes of robots that serve customers at exhibition halls and the like are being developed, and trials are being conducted in actual customer service situations.

For example, when each robot detects that a customer exists in front of itself, each robot starts serving the customer with a presentation or the like.

JP 2015-66625 A JP 2008-142876 A JP 2008-254122 A JP 2009-248193 A

However, if another customer appears in front of the robot after the robot starts presenting it to a customer, the other customer will view the presentation from the middle. As a result, a situation arises in which the other customer cannot be served sufficiently.

Therefore, in one aspect, an object of the present invention is to improve the quality of customer service by a robot.

In one aspect, the control program is interested in one of a plurality of robots providing services in the specific area based on first information indicating the direction of interest of each person present in the specific area. and based on the second information indicating whether each robot is providing a service, it is determined whether any of the robots is providing a service. a process of determining, if any of the robots is providing a service, a process of identifying other robots that are not providing the service among the plurality of robots based on the second information; an information processing device capable of communicating with the plurality of robots to output an instruction for starting service provision to the specified other robot.

As one aspect, the quality of customer service by robots can be improved.

It is a figure which shows the 1st example of the customer service which becomes possible in embodiment of this invention. It is a figure which shows the 2nd example of the customer service which becomes possible in embodiment of this invention. It is a figure which shows the system configuration example in embodiment of this invention. 1 is a diagram showing a hardware configuration example of a server device 10 according to an embodiment of the present invention; FIG. It is a figure which shows the hardware structural example of the robot 20 in embodiment of this invention. 2 is a diagram illustrating functional configuration examples of a server device 10 and a robot 20 according to an embodiment of the present invention; FIG. 4 is a flowchart for explaining an example of a processing procedure executed by the server apparatus 10; FIG. 10 is a diagram showing an example of a state transition model of service scenarios; FIG. 4 is a diagram showing a configuration example of a service scenario; FIG. 2 is a diagram for explaining an example of a serviceable range; FIG. FIG. 11 is a flowchart for explaining an example of a processing procedure for setting a coordinate system of the entire space; FIG. FIG. 11 is a flowchart for explaining an example of a processing procedure of service scenario matching processing; FIG. 4 is a flow chart for explaining an example of a processing procedure of processing for grasping the current position of each robot 20. FIG. It is a figure which shows the structural example of robot general|segmentation DB123. It is a flowchart for demonstrating an example of the processing procedure of the grasping|ascertainment process of each customer's presence and interest. It is a figure which shows the structural example of presence interest historical information. It is a figure which shows the structural example of presence interest information. FIG. 11 is a flowchart for explaining an example of a processing procedure of service establishment level determination processing; FIG. It is a figure which shows the structural example of a customer list. It is a figure which shows the structural example of service progress information. It is a figure which shows the structural example of investigation DB124. FIG. 10 is a flowchart for explaining an example of a processing procedure of customer status investigation processing; FIG. FIG. 10 is a flowchart for explaining an example of a processing procedure of customer status investigation processing; FIG. FIG. 10 is a flowchart for explaining an example of a processing procedure for identifying a customer whose service establishment level is unreasonably low; FIG. FIG. 10 is a flowchart for explaining an example of a processing procedure of peripheral robot identification processing; FIG. 4 is a diagram showing a configuration example of a peripheral robot DB 126; FIG. FIG. 11 is a flowchart for explaining an example of a processing procedure of countermeasure candidate determination processing; FIG. It is a figure for demonstrating a reservation countermeasure. It is a figure for demonstrating the piggybacking countermeasure. It is a figure for demonstrating a replacement countermeasure. It is a figure for demonstrating the spot correspondence countermeasure. FIG. 10 is a diagram for explaining countermeasures for dealing with order change spots; FIG. 11 is a flowchart for explaining an example of a processing procedure of determination processing of a reserved countermeasure; FIG. It is a figure which shows the structural example of various countermeasure information. 10 is a flowchart for explaining an example of a processing procedure for determining processing for piggybacking countermeasures; FIG. 11 is a flowchart for explaining an example of a processing procedure of a replacement countermeasure determination process; FIG. FIG. 11 is a flowchart for explaining an example of a processing procedure of spot countermeasure determination processing; FIG. FIG. 11 is a flowchart for explaining an example of a processing procedure of determination processing for countermeasures against order-changed spots; FIG. FIG. 11 is a flowchart for explaining an example of a processing procedure of countermeasure selection processing; FIG. FIG. 11 is a flowchart for explaining an example of a processing procedure of countermeasure output processing; FIG. 10 is a flowchart for explaining an example of a processing procedure executed by a presence interest information generating unit 218. FIG. 4 is a flowchart for explaining an example of a processing procedure executed by a service control unit 221; FIG. 10 is a flowchart for explaining an example of a processing procedure of countermeasure instruction processing; FIG. 4 is a flowchart for explaining an example of a processing procedure executed by a service execution unit 222; 4 is a flowchart for explaining an example of a processing procedure executed by an interaction unit 220; 4 is a flowchart for explaining an example of a processing procedure executed by an interaction unit 220; 4 is a flowchart for explaining an example of a processing procedure executed by an interaction unit 220; 3 is a diagram illustrating a configuration example of an operation log storage unit 251; FIG. 3 is a diagram illustrating a configuration example of an operation log storage unit 252; FIG. 4 is a flowchart for explaining an example of a processing procedure executed by a position measurement unit 212;

BEST MODE FOR CARRYING OUT THE INVENTION An embodiment of the present invention will be described below based on the drawings. First, an example of customer service by the robot 20 enabled in the embodiment of the present invention will be described.

FIG. 1 is a diagram showing a first example of customer service that is possible in the embodiment of the present invention. In FIG. 1, customer service progresses in order from time t1 to time t4. In FIG. 1, the robots 20-1 and 20-2 are waiting for customers.

At time t1, when the human customer c1 appears in front of the robot 20-1, the robot 20-1 starts giving a presentation to the customer c1.

At time t2, the customer c2 appears in front of the robot 20-1 after the presentation of the robot 20-1 has started.

At time t3, when customer c3 appears in front of robot 20-2, robot 20-2 attempts to start a presentation to customer c3. He notices the existence of a customer c2 who has only received.

Therefore, at time t4, the robot 20-2 notifies the start of the presentation to the customer c2, and starts the presentation to the customers c2 and c3 from the beginning. As a result, it is possible to avoid missing the customer c2.

FIG. 2 is a diagram showing a second example of customer service that is possible in the embodiment of the present invention. Also in FIG. 2, the robots 20-1 and 20-2 are waiting for customers.

At time t1, when the customer c1 appears in front of the robot 20-1, the robot 20-1 starts giving a presentation to the customer c1.

At time t2, when the customer c2 appears in front of the robot 20-2, the robot 20-2 starts giving a presentation to the customer c2.

At time t3, the customer c3 appears in front of the robot 20-2 after the presentation of the robot 20-2 has started.

At time t4, the presentation to customer c1 by robot 20-1 ends. As a result, the robot 20-1 is released from serving customers.

Therefore, at time t5, the robot 20-1 takes over the presentation for the customer c2 from the robot 20-2. That is, the robot 20-1 starts presentation to the customer c2 after the portion already provided by the robot 20-2 to the customer c2 (that is, the unprovided service portion).

At time t6, the robot 20-2 released from the customer c2 starts the presentation to the customer c3 from the beginning. As a result, it is possible to avoid missing the customer c3.

In order to enable the above customer service, the present embodiment employs, for example, the following system configuration. FIG. 3 is a diagram showing a system configuration example according to the embodiment of the present invention. In FIG. 3, a plurality of robots 20 such as robots 20-1, 20-2, and 20-n (hereinafter referred to as "robots 20" when not distinguished from each other) serve customers, for example, in a specific area such as an exhibition hall. It is a communication robot that performs Each robot 20 is connected to the network N1 via a wireless communication network such as a wireless LAN. A server device 10 is connected to the network N1. Therefore, each robot 20 and the server device 10 can communicate with each other. Each robot 20 may be fixed at a predetermined position, or may be movable.

The server device 10 is one or more computers (information processing devices) that control each robot 20 . For example, the server device 10 controls each robot 20 in order to realize the handover and the like between the robots 20 described at time t3 in FIG. 1 and time t5 in FIG.

FIG. 4 is a diagram showing a hardware configuration example of the server device 10 according to the embodiment of the present invention. In FIG. 4, the server device 10 has a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, etc., which are connected to each other via a bus B, respectively.

A program for realizing processing in the server device 10 is provided by the recording medium 101 . When the recording medium 101 recording the program is set in the drive device 100 , the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100 . However, the program does not necessarily need to be installed from the recording medium 101, and may be downloaded from another computer via the network. The auxiliary storage device 102 stores installed programs, as well as necessary files and data.

The memory device 103 reads out and stores the program from the auxiliary storage device 102 when a program activation instruction is received. The CPU 104 executes functions related to the server device 10 according to programs stored in the memory device 103 . The interface device 105 is used as an interface for connecting to the network N1.

An example of the recording medium 101 is a portable recording medium such as a CD-ROM, a DVD disk, or a USB memory. An example of the auxiliary storage device 102 is an HDD (Hard Disk Drive) or a flash memory. Both the recording medium 101 and the auxiliary storage device 102 correspond to computer-readable recording media.

FIG. 5 is a diagram showing a hardware configuration example of the robot 20 according to the embodiment of the present invention. 5, the robot 20 has a CPU 201, an auxiliary storage device 202, a memory device 203, a wireless communication device 204, a UI device 205, a human sensor 206, a camera 207, a microphone 208, a speaker 209, a GPS receiver 210, and the like.

A program for controlling the robot 20 is installed in the auxiliary storage device 202 . The memory device 203 reads out and stores the program from the auxiliary storage device 202 when a program activation instruction is received. The CPU 201 executes functions related to the robot 20 according to programs stored in the memory device 203 . The wireless communication device 204 functions as an interface for performing wireless communication with the server device 10 and the like. The UI device 205 is a group of devices that function as a user interface, such as a touch panel and various buttons.

A human sensor 206 is a human sensor for detecting the presence of a customer. The camera is a digital camera. A microphone is a microphone for inputting speech of a customer or the like. A speaker is a speaker for outputting voice to the customer. The GPS receiver 210 receives GPS radio waves from GPS satellites. In FIG. 5, the drive system hardware for operating the robot 20 is omitted for the sake of convenience.

FIG. 6 is a diagram showing a functional configuration example of the server device 10 and the robot 20 according to the embodiment of the present invention. In FIG. 6, the server device 10 includes an overall space comprehension unit 11, a scenario matching unit 12, a robot position comprehension unit 13, a presence/interest comprehension unit 14, a service availability level determination unit 15, a peripheral robot identification unit 16, and a countermeasure candidate determination unit. 17, a countermeasure selection unit 18, a countermeasure output unit 19, and the like. Each of these units is implemented by processing that one or more programs (control programs) installed in the server apparatus 10 cause the CPU 104 to execute. The server device 10 also uses databases (storage units) such as a spatial information DB 121, a scenario DB 122, a robot general DB 123, a survey DB 124, an unjust customer DB 125, a peripheral robot DB 126, a countermeasure candidate DB 127, and a countermeasure DB 128. Each of these databases can be implemented using, for example, the auxiliary storage device 102 or a storage device that can be connected to the server device 10 via a network.

The overall space grasping unit 11 executes setting processing of the coordinate system of the overall space. Here, the overall space refers to the range of specific areas such as exhibition halls, amusement parks, public squares, entertainment facilities, etc. where the robot 20 provides services. Information about the entire space is stored in the space information DB 121 .

The scenario matching unit 12 performs service scenario matching processing with each robot 20 . In the service scenario matching process, the contents of the service scenario held by each robot 20 and the service scenario held by the server device 10 are matched. A service scenario is data defining a scenario of a service (customer service) provided by the robot 20 . Service scenarios are stored in the scenario DB 122 .

The robot position grasping unit 13 grasps the current position of each robot 20 in the entire space. Information about each robot 20 in the entire space is stored in the robot generalization DB 123 . The presence/interest grasping unit 14 grasps the presence and direction of interest of each customer.

The service establishment level determination unit 15 determines the service establishment level for each customer, and identifies customers whose service establishment level is unreasonably low. The service establishment level is a concept indicating the degree to which the service (customer service such as presentation) by the robot 20 is appropriately performed. From the customer's point of view, the service establishment level is an index group for evaluating the degree of satisfaction with the service provided by the robot 20 . The higher the service establishment level, the higher the possibility that the service provided by the robot 20 is appropriately performed (the possibility that the customer is satisfied with the service provided by the robot 20). The survey DB 124 stores the results of various surveys performed by the service establishment level determination unit 15 to determine the service establishment level.

The surrounding robot identification unit 16 identifies the robots 20 existing in the vicinity of each customer determined to have an unreasonably low service establishment level. Information about the robots 20 specified by the peripheral robot specifying unit 16 is stored in the peripheral robot DB 126 .

The countermeasure candidate determination unit 17 determines candidates for countermeasures (countermeasure candidates) that can be implemented to increase the service establishment level of each customer determined to have an unreasonably low service establishment level. Information about the candidate countermeasures determined to be feasible by the candidate countermeasure determination unit 17 is stored in the candidate countermeasure DB 127 .

The countermeasure selection unit 18 selects a countermeasure to be actually implemented from the countermeasure candidates stored in the countermeasure candidate DB 127 . Information about the selected countermeasure is stored in the countermeasure DB 128 .

The countermeasure output unit 19 outputs (transmits) an execution instruction for the countermeasure selected by the countermeasure selection unit 18 to the robot 20 involved in the countermeasure.

On the other hand, each robot 20 includes a scenario management unit 211, a position measurement unit 212, an operation detection unit 213, an existence recognition unit 214, an existence direction recognition unit 215, an existence distance recognition unit 216, an interest direction recognition unit 217, and an existence interest information generation unit. 218, an operation log generation unit 219, an interaction unit 220, a service control unit 221, a service execution unit 222, and the like. Each of these units is realized by processing that one or more programs (control programs) installed in the robot 20 cause the CPU 201 to execute. The robot 20 also uses an operation log storage unit 251, an action log storage unit 252, a presence interest information storage unit 253, a scenario storage unit 254, and the like. Each of these storage units can be implemented using, for example, the auxiliary storage device 202 or the memory device 203 or the like.

The scenario management unit 211 manages service scenarios stored in the scenario storage unit 254 . For example, the scenario management unit 211 updates the service scenario according to instructions from the server device 10 .

The position measurement unit 212 measures the current position of the robot 20 . The operation detection unit 213 detects an operation of the robot 20 by the customer, and stores log information (hereinafter referred to as “operation log”) regarding the operation in the operation log storage unit 251 .

The presence recognition unit 214 recognizes the presence of each customer around the robot 20 . The existing direction recognition unit 215 recognizes the direction of each customer as seen from the robot 20 . The existence distance recognition unit 216 recognizes the distance from the robot 20 for each customer. The direction-of-interest recognition unit 217 recognizes the direction of interest of each customer. The existence interest information generation unit 218 periodically generates information indicating the recognition results by the existence recognition unit 214, the existence direction recognition unit 215, and the interest direction recognition unit 217 (hereinafter referred to as "existence interest information"). The existence interest information is stored in the existence interest information storage unit 253 .

The action log generation unit 219 generates log information (hereinafter referred to as “action log”) regarding the action of the robot 20 and stores the action log in the action log storage unit 252 .

The interaction unit 220 responds to an inquiry about whether or not various situations have occurred from the service establishment level determination unit 15 of the server device 10, based on the history of existence/interest information, the history of operation logs, the history of operation logs, and the like. It judges whether or not there is a situation where the

The service control unit 221 controls execution of services by the robot 20 . For example, the service control unit 221 determines which customer in the vicinity of the robot 20 should be serviced, and instructs the service execution unit 222 to perform the service for that customer. When the service control unit 221 receives a countermeasure from the server device 10, the service control unit 221 instructs the service execution unit 222 to execute a service according to the countermeasure.

The service execution unit 222 executes services for customers according to instructions from the service control unit 221 .

Processing procedures executed by the server device 10 or the robot 20 will be described below. FIG. 7 is a flowchart for explaining an example of a processing procedure executed by the server device 10. As shown in FIG.

After starting the process, the server apparatus 10 continuously executes step S102 and subsequent steps until an end instruction is input (S101).

In step S102, the overall space comprehension unit 11 executes processing for setting the coordinate system of the overall space.

Subsequently, the scenario matching unit 12 executes service scenario matching processing (S103). In this embodiment, service scenarios are defined based on the following state transition model.

FIG. 8 is a diagram showing an example of a state transition model of a service scenario. As shown in FIG. 8, the service scenario of this embodiment has three states, a pre-service state, a core value provision state, and an after-sales service state, and the states transition in this order.

The pre-service state is a state in which preparatory work for providing the original service (hereinafter referred to as "core value"), such as service start notice and self-introduction, is executed. The core value provision state is a state in which a core value such as presentation is provided. The after-sales service state is a state in which work for terminating the service, such as greetings for the end of the service, is executed.

Note that each state includes one or more phases. Each phase is classified into a phase with high predictability of required time and a phase with low predictability of required time. A phase with a highly predictable duration is a phase in which the duration is approximately the same for each execution of the service. For example, a phase of reproducing a moving image for a predetermined time is an example of a phase in which the required time is highly predictable. A phase in which the required time is less predictable means a phase in which the required time may change significantly for each service execution. For example, the Q&A phase is an example of a phase with a low predictability of duration.

A service scenario generated according to a state transition model as shown in FIG. 8 is delivered in advance to each robot 20 .

FIG. 9 is a diagram showing a configuration example of a service scenario. As shown in FIG. 9, the service scenario includes "phase number", "phase name", "state", "control information", "average time", "deviation", "order" for each phase constituting the service. changeability” and “interaction degree”.

"Phase number" is the identification number of the phase. "Phase name" is the name of the phase. The name simply indicates the content of the phase. "State" is an item indicating which state the phase belongs to in the state transition model shown in FIG. 8, and is set with a value of "pre", "core" or "after". "Pre" indicates a pre-service state. "Core" indicates the core value provision state. "After" indicates the state of after-sales service. The “control information” is information for controlling the motion, utterance content, etc. of the robot 20 in the phase. "Average time" is the average value of the duration of the phase. "Deviation" is the deviation of the duration of the phase. The "deviation" value is used to determine the predictability of the required time. “Possibility of order change” is an item indicating the possibility of changing the order of the phases. For phases whose order can be changed, the phase number of the candidate phase for the destination is set to "order changeability". "Interaction degree" indicates the degree of interaction (dialogue or exchange, etc.) between the robot 20 and the customer, and is set to "high", "medium" or "low". For example, the degree of interaction is "low" in phases where there is a high possibility that no interaction will occur between the robot 20 and the customer, such as video playback.

In the present embodiment, it is assumed that the relationship between the server device 10 and each robot 20 is a simple connection, that is, each robot 20 moves autonomously to some extent. For example, at an exhibition hall, it is assumed that the service scenario in which the individual robots 20 are operating is corrected (rewritten) on the spot (according to the needs of the spot) by the explainer. In this case, the server apparatus 10 needs to grasp such correction immediately. Otherwise, the server device 10 cannot accurately grasp the situation of each robot 20, and there is a possibility that an inconvenience may occur when generating countermeasures or the like. Also, there may be a case where the server device 10 wants to correct a common service scenario referenced by individual robots 20 . Therefore, in step S103, the service scenarios to be executed are made consistent between each robot 20 and the server device 10. FIG.

Subsequently, the robot position grasping unit 13 executes processing for grasping the current position of each robot 20 in the entire space (S104). Subsequently, the presence/interest grasping unit 14 executes a process of grasping the presence and interest of each customer (S105). Through this processing, for each robot 20 operating in the entire space, the number of customers existing within the serviceable range, the distance of each customer from the robot 20, and each customer starting from the robot 20 integrated presence/interest history information including the history of the presence direction of the customer, the direction of interest of each customer, and the like.

FIG. 10 is a diagram for explaining an example of a serviceable range. FIG. 10 shows an example in which the range of a cylinder centered on the robot 20 and having a base of a circle with a radius of r and a height of h is the service-providable range. Note that the values of r and h are set in advance.

Subsequently, the service establishment level determination unit 15 determines whether or not a customer exists within the serviceable range of any of the robots 20 (S106). Such a determination can be made with reference to integrated presence interest history information. This is because the integrated presence/interest history information includes, for each robot 20, information indicating the number of customers within the serviceable range.

If there is no customer located within the serviceable range of any of the robots 20 (No in S106), the process returns to step S101. If one or more customers (hereinafter referred to as "candidate customers") exist within any serviceable range (Yes in S106), the service establishment level determination unit 15 executes service establishment level determination processing (S107). ).

Subsequently, the service establishment level determination unit 15 executes a process of identifying a customer whose service establishment level is unreasonably low (S108). How a state with a low service establishment level is evaluated will be described later. Specifically, candidate customers corresponding to customer c2 at time t2 in FIG. is determined.

If there is no candidate customer whose service establishment level is unreasonably low (No in S109), the process returns to step S101. If there is a candidate customer with an unreasonably low service establishment level (hereinafter referred to as an "improper customer") (Yes in S109), the peripheral robot identification unit 16 executes peripheral robot identification processing (S110). In the peripheral robot identification process, the robots 20 existing in the vicinity of the unfair customer are identified as the peripheral robots 20 for each unfair customer.

Subsequently, the peripheral robot identification unit 16 determines whether or not there is an unauthorized customer for whom the peripheral robot 20 has been identified (S111). If there is no unauthorized customer for which the peripheral robot 20 has been identified (that is, if there is no robot 20 in the vicinity of any unauthorized customer) (No in S111), the process returns to step S101. If there is an unfair customer for whom the peripheral robot 20 has been identified (Yes in S111), the countermeasure candidate determination unit 17 executes a countermeasure candidate determination process (S112). In the countermeasure candidate determination process, one or more executable countermeasure candidates (countermeasure candidates) are determined for each of the unauthorized customers so as to enable customer service (execution of service) by any of the peripheral robots 20. . Unauthorized customers for whom there are no viable countermeasure candidates are determined to be incapable of handling.

If there is no unjust customer with a countermeasure candidate (No in S113), the process returns to step S101. If there is an unjust customer with a countermeasure candidate (Yes in S113), the countermeasure selection unit 18 executes countermeasure selection processing (S114). In the countermeasure selection process, a countermeasure to be actually executed is selected from the executable countermeasure candidates.

Subsequently, the countermeasure output unit 19 executes a countermeasure output process (S115). In the countermeasure output process, an instruction for implementing the countermeasure is output (transmitted) to each robot 20 involved in the countermeasure selected in the countermeasure selection process. For example, in the case of FIG. 1, an instruction is sent to the robot 20-2 to correspond to the customer c2. In the case of FIG. 2, an instruction is sent to the robot 20-1 and the robot 20-2 so that the robot 20-2 takes over the handling of the customer c2 from the robot 20-2 to the robot 20-1. Also, an instruction is sent to the robot 20-2 to make it correspond to the customer c3.

Subsequently, the server device 10 waits until a predetermined condition is satisfied (S116). The predetermined condition may be any condition as long as it is expected that the processing results after step S106 (for example, the determination results of S106, S109, S111, S113, etc.) can be expected to change. Examples of the predetermined conditions include elapse of a certain period of time, changes in the distribution of customer locations, changes in the distribution of the locations of the robots 20, changes in the number of operable robots 20, and the like. If the predetermined condition is satisfied (Yes in S116), steps S101 and subsequent steps are repeated.

Next, details of step S102 will be described. FIG. 11 is a flowchart for explaining an example of a processing procedure for setting the coordinate system of the entire space.

In step S<b>201 , the overall space comprehension unit 11 acquires spatial information on the overall space from the spatial information DB 121 . Spatial information refers to coordinate information indicating a space such as an exhibition hall. For example, when an exhibition hall or the like is modeled as a rectangular parallelepiped, a set of three-dimensional coordinate values of each vertex may be used as spatial information.

Subsequently, the overall space comprehension unit 11 acquires spatial information of objects existing in the overall space from the spatial information DB 121 (S202). An object that exists in the entire space is an object that limits the existing position of the robot 20 in the entire space. For example, desks, walls, screens, etc. are examples of such objects. The spatial information of objects existing in the entire space is relative spatial information of each object with respect to the spatial information of the entire space.

Subsequently, the overall space grasping unit 11 determines whether or not at least one of the spatial information of the overall space and the spatial information of the object is different from the previously (finally) acquired spatial information (S203).

If at least one of the spatial information of the entire space and the spatial information of the object is different from the last acquired spatial information (Yes in S203), the overall space grasping unit 11 collects the spatial information of the entire space and the spatial information of the object. By synthesizing the information, spatial information of the entire service provision space (hereinafter referred to as "service provision entire space information") is generated, and the service provision entire space information stored in the memory device 103 is newly generated. It is updated with the service provision overall space information (S204). Combining the spatial information of the entire space and the spatial information of the object means, for example, defining the spatial information of the object as a space in which the robot 20 cannot move in the spatial information of the entire space. Therefore, for example, the space obtained by subtracting the object space from the overall space corresponds to the overall service provision space, and the coordinate information indicating the overall service provision space corresponds to the overall service provision space information.

Next, details of step S103 in FIG. 7 will be described. FIG. 12 is a flowchart for explaining an example of a processing procedure for service scenario matching processing. Although not shown in FIG. 9, each service scenario is provided with a scenario ID, update date and time, and the like.

In step S<b>211 , the scenario matching unit 12 receives from the scenario management unit 211 of each robot 20 the robot ID of the robot 20 , the scenario IDs of the service scenarios stored in the scenario storage unit 254 of the robot 20 , and the updated scenarios. Get the date and time.

Next, based on the scenario ID and update date and time acquired from each robot 20, the scenario matching unit 12 determines that the service scenario has been partially corrected on the robot 20 side, or that the service scenario has been procured from other than the server device 10. It is determined whether or not there is a service scenario to be used (S212). For example, in the service ID group acquired from each robot 20, there is a service ID that matches the original service ID of one of the service scenarios stored in the scenario DB 122 of the server device 10 but has a different update date and time. , it is determined that there is a service scenario that is considered to be partially corrected on the robot 20 side. Further, if the group of service IDs acquired from each robot 20 includes a service ID that does not match the original service ID of any service scenario stored in the scenario DB 122 of the server device 10, the It is determined that there is a service scenario that is considered procured.

If it is determined in step S212 that there is a corresponding service scenario (Yes in S212), the scenario matching unit 12 selects the corresponding service scenario based on the scenario ID of the service scenario, 20, and the acquired service scenario is stored in the scenario DB 122 in association with the robot ID of the robot 20 from which it was acquired (S213).

In the case of No in step S212, or following step S213, the scenario matching unit 12 receives a request for partial correction or new addition of the service scenario to each robot 20 by an operation by the administrator or an automatic judgment by the server device 10. It is determined whether or not it is stored in the scenario DB 122 (S213). The partial correction request includes, for example, the scenario ID of the service scenario to be corrected, and identification information of the correction portion (eg, "phase", etc.). In addition, when partial correction requests are limited to some robots 20, the robot IDs of the robots 20 may be included in the partial correction request. On the other hand, the new addition request includes a service scenario to be newly added. Further, when the robots 20 to which the new addition is requested are limited to some robots 20, the robot ID of the robot 20 may be included in the new addition request.

If there is a corresponding request (Yes in S213), the scenario matching unit 12 transmits the request to the scenario management unit 211 of the robot 20 (S214). The scenario matching unit 12 transmits the request limited to the robot 20 as the request destination only to the robot 20 as the request destination. As a result, the correction of the existing service scenario or the addition of the new service scenario is reflected in the scenario storage unit 254 of the robot 20 to which the request is sent.

Next, the details of step S104 will be described. FIG. 13 is a flowchart for explaining an example of the processing procedure of the current position grasping processing of each robot 20 .

In step S<b>221 , the robot position grasping unit 13 acquires a robot list indicating a list of robot information of the robots 20 currently in operation from the robot general DB 123 .

FIG. 14 is a diagram showing a configuration example of the robot generalization DB 123. As shown in FIG. As shown in FIG. 14, the robot general DB 123 includes "robot ID", "operation status", "specification address", "position list address" and the like for each robot 20 that is a candidate for operation.

“Robot ID” is identification information of the robot 20 . In this embodiment, the robot ID also functions as address information (for example, IP address) for communication with each robot 20 for the server device 10 . “Operating status” is information indicating the current operating status of the robot 20 . The operation status includes "in operation", "power off", "inspection/testing", and the like. “Specification address” is address information (for example, file path name or URL (Uniform Resource Locator)) of the storage location of the specification information of the robot 20 . “Position list address” is address information of the storage location of the time-series history (position list) of the location of the robot 20 . Each record of the position list includes "date and time", "X coordinate value", "Y coordinate value" and "Z coordinate value", etc., as shown in FIG. The “date and time” is the date and time when the position of the robot 20 was measured. "X coordinate value", "Y coordinate value" and "Z coordinate value" are the X coordinate value, Y coordinate value and Z coordinate value of the existing position of the robot 20 in the entire space.

Next, the robot position grasping unit 13 acquires the GPS coordinates of each robot 20 by inquiring about the GPS coordinates of the current position of each robot 20 corresponding to each robot information included in the acquired robot list. (S222). Subsequently, the robot position grasping unit 13 obtains the GPS coordinates of a predetermined reference point for the entire space by a known method (S223).

Subsequently, the robot position grasping unit 13 acquires the global coordinate system from the spatial information DB 121 (S224). Next, based on the GPS coordinates of the reference point in the entire space and the coordinates of the reference point in the global coordinate system, the robot position grasping unit 13 obtains conversion information between the GPS coordinate system and the global coordinate system (for example, a conversion matrix etc.) is generated (S225).

Subsequently, the robot position grasping unit 13 converts the GPS coordinates acquired from each robot 20 into coordinates of the global coordinate system (hereinafter referred to as "global coordinates") based on the conversion information (S226). The robot position grasping unit 13 adds to the position list of each robot 20 a record containing the current date and time and the X, Y, and Z coordinates of the global coordinates.

Next, details of step S105 will be described. FIG. 15 is a flow chart for explaining an example of a processing procedure for grasping the presence and interest of each customer.

In step S<b>231 , the presence/interest grasping unit 14 acquires the entire spatial coordinate system from the spatial information DB 121 . Subsequently, the existence/interest grasping unit 14 acquires a robot list indicating a list of robot information of the currently operating robots 20 from the robot general DB 123 (FIG. 14) (S232).

Next, the presence/interest grasping unit 14 obtains the coordinate information of the service-providable range (FIG. 10) of each robot 20 whose “operation status” value in the robot information is “in operation”, and the presence/interest information. History information is acquired (S233). The coordinate information of the serviceable range (FIG. 10) is, for example, the coordinate value of the central position of the serviceable range. However, since the center position is the existing position of the robot 20, the coordinate values may be obtained from the latest record in the position list.

Presence/interest history information is information indicating the history of the presence and interest of customers detected by the robot 20 . FIG. 16 is a diagram showing a configuration example of existence interest history information.

As shown in FIG. 16, the existence interest history information includes one robot ID, one or more change occurrence times, and one or more existence interest information for each change occurrence time.

The change occurrence time is the time when a change equal to or greater than a threshold occurs in the existence interest information. That is, one or more presence interest information (that is, the history of human presence monitoring information) detected or measured until a change equal to or greater than the threshold occurs is associated with the same change occurrence time.

Presence/interest information is information indicating the presence, interest, etc. of a customer detected by the robot 20 at a certain point in time.

FIG. 17 is a diagram showing a configuration example of existence interest information. As shown in FIG. 17, one piece of existence interest information includes "generation time", "additional number", "number of people within range", "customer ID within range", "existence direction vector within range", "existence within range distance", "interest vector within range", "number of people out of range", "customer ID out of range", "existence direction vector out of range", "existence distance out of range", "direction vector of interest out of range", "existence judgment source data ID”, “existence direction determination source data ID”, “existence distance determination source data ID”, “interest direction determination source data ID”, and the like.

The “creation time” is the creation time of the existence interest information. "Additional number" is a subsequent number (serial number) of the existence interest information. That is, consecutive numbers are assigned to each piece of presence interest information. One "creation time" corresponds to one "additional number".

The "number of people within range" indicates the number of customers whose presence was recognized within the service provisionable range of the robot 20 that generated the presence interest information at the time of "generation time".

“Customer ID within range” is a customer ID generated by the robot 20 for each customer related to “Number of people within range”. In this embodiment, the same customer ID is always generated for the same customer. The "customer ID within the range" has a list structure corresponding to the "number of people within the range". That is, the size of the list is "number of people within range" x (customer ID).

The "in-range existence direction vector" indicates a vector (X, Y, Z) with the position of the robot 20 as the starting point for the position of each customer related to the "number of people in the range". The 'in-range existence direction vector' has a list structure corresponding to the 'number of people in the range'. That is, the size of the list is "the number of people within the range"×(X value, Y value, Z value).

“Existence distance within range” indicates the distance (L) from the robot 20 to the position of each customer related to “number of customers within range”. The “existence distance within range” has a list structure corresponding to the “number of people within range”. That is, the size of the list is "the number of people within the range"×(L value).

"Direct vector of interest within range" indicates the vector (X, Y, Z) of the direction of interest of each customer related to the "number of people within range". A vector indicating the direction of the customer's interest is set in the "in-range interested direction vector". The "direction vector of interest within range" has a list structure corresponding to the "number of people within range". That is, the size of the list is "number of people within range"×(X value, Y value, Z value). In addition, NULL is set for a customer whose direction of interest has not been detected at the "creation time".

It should be noted that the order of data in each of the lists of "existence direction vector within range", "existence distance within range", and "direction vector of interest within range" corresponds to the order of customer IDs in the "customer ID within range".

"Number of customers out of range" indicates the number of customers whose presence was recognized by the robot 20 outside its own serviceable range at the time of "creation time".

The “out-of-range customer ID” is the customer ID recognized by the robot 20 for each customer related to the “out-of-range number of people”. The data structure of the "out-of-range customer ID" is the same as that of the "in-range customer ID".

The “out-of-range presence direction vector” indicates a vector (X, Y, Z) with the robot 20 as the starting point for the position of each customer related to the “out-of-range number of people”. The data structure of the "out-of-range existence direction vector" is the same as that of the "in-range existence direction vector".

The “existence distance out of range” indicates the distance (L) from the robot 20 to the position of each customer related to the “number of customers out of range”. The data structure of the "existence distance outside the range" is the same as that of the "existence distance within the range".

The "out-of-range interested direction vector" indicates the vector (X, Y, Z) of the direction of interest of each customer related to the "out-of-range number of people". The data structure of the "out-of-range direction vector of interest" is similar to that of the "in-range direction of interest vector".

The order of data in each of the lists of "out-of-range existence direction vector", "out-of-range existence distance", and "out-of-range interest direction vector" corresponds to the order of customer IDs in the "out-of-range customer ID" list.

The “existence determination source data ID” is the ID of the data (image data, etc.) that is the basis for recognizing the presence of the customer. The “existence direction determination source data ID” is the ID of the data (image data, etc.) that is the basis for recognizing the customer's existence direction. "Existence distance determination source data ID" is the ID of the data (image data, etc.) used as the basis for recognition of the customer's distance. "Interested direction determination source data ID" is the ID of the data (image data, etc.) used as the basis for recognition of the customer's direction of interest.

In addition, in step S233, existence interest history information including existence interest information generated between the current time and a predetermined time ago may be acquired.

The existence interest grasping unit 14 generates integrated existence interest history information based on the coordinate information of the serviceable range and the existence interest history information acquired from each robot 20 (S234). The integrated existence interest history information is list-structured data whose elements are information in which the coordinate information of the serviceable range acquired from each robot 20 and the existence interest history information are associated. That is, the integrated existence interest history information includes the existence interest history information acquired from each robot 20 .

In addition, based on various sensors (for example, cameras, infrared rays, human sensors, pressure mats spread on the floor, etc.) installed in the entire space separately from the robot 20, the server device 10 side is integrated presence interest history information may be generated, and the integrated presence interest history information generated based on the presence interest history information acquired from the robot 20 may be complemented by the integrated presence interest history information generated by the server device 10 .

In step S106 of FIG. 7, based on the "number of people within range" of the latest presence interest history information of each robot 20, it is determined whether or not there is a customer within the service provision range of any of the robots 20. good.

Next, the details of step S107 in FIG. 7 will be described. FIG. 18 is a flowchart for explaining an example of the processing procedure of service establishment level determination processing.

In step S241, the service establishment level determination unit 15 generates a customer list based on the integrated existence interest history information.

FIG. 19 is a diagram showing a configuration example of a customer list. A customer list is list-structured data containing one or more pieces of customer information. One piece of customer information is information about one customer included in the serviceable range of any of the robots 20, and includes a "customer ID", one or more "robot IDs", and a "dialogue ratio value" for each "robot ID". ” and “sum of action values”.

The “customer ID” is one customer ID included in the “in-range customer ID” of the latest existence interest information of any of the existence interest history information constituting the integrated existence interest history information. The "robot ID" is the robot ID of the robot 20 that includes the customer ID related to the "customer ID" in the "range customer ID" of the latest existence interest information. The “dialogue ratio value” is a dialogue ratio value calculated for a set of the customer associated with the “customer ID” and the robot 20 associated with the “robot ID”. When a plurality of robot IDs are associated with one customer ID, the dialogue ratio value is calculated for each set of the customer associated with the customer ID and each of the plurality of robots 20 . The “sum of action values” is the sum of action values used to calculate the “dialogue ratio value”. Details of the dialogue ratio value and the action value will be described later.

The reason why a plurality of robot IDs may correspond to one customer ID (that is, one customer) is that there is a possibility that a customer exists in an overlapping area of the service provision range of a plurality of robots 20. Because there is. In other words, multiple robot IDs are associated with the customer ID of a customer existing in such an overlapping area. Note that there is no restriction on the order in which customer information is arranged in the customer list.

Subsequently, the service establishment level determination unit 15 substitutes 1 for the variable i (S242). A variable i is a variable indicating the order of customer information to be processed in the customer list. Subsequently, the service establishment level determination unit 15 substitutes 1 for the variable j (S243). A variable j is a variable indicating a robot ID to be processed among the robot IDs included in the customer information (i).

Subsequently, the service establishment level determination unit 15 acquires the i-th customer information (hereinafter referred to as "customer information (i)") in the customer list (S244). A customer ID included in the customer information (i) is referred to as "customer ID (i)".

Subsequently, the service establishment level determination unit 15 acquires service progress information from the robot 20 associated with each robot ID included in the customer information (i) (S245). The service progress information is information indicating the service provision state (service progress state) by the robot 20 .

FIG. 20 is a diagram showing a configuration example of service progress information. As shown in FIG. 20, the service progress information acquired from one robot 20 includes "status", "service instance ID", "target customer ID", "service start time", "end phase", " In-progress phase” and “phase elapsed time” are included.

"Status" is an item indicating whether or not the service is being executed, and is "1" if the service is being executed and "0" if the service is not being executed. However, as will be described later, a robot 20 that is not executing a service does not have service progress information. Therefore, the "status" of the acquired service progress information is basically "1". "Service instance ID" is an ID assigned for each service execution. "Target customer ID" is the customer ID of the customer to whom the service is provided. The service start time is the start time of execution of the service associated with the "service instance ID". "End phase" is the phase number of the phase that has already ended in the execution of the service. The "current phase" is the phase number of the phase currently being executed. The "phase elapsed time" is the elapsed time of the "current phase".

Subsequently, the service establishment level determination unit 15 determines whether or not the customer associated with the customer ID (i) is receiving service provided by any robot 20 based on the acquired service progress information (S246). ). Specifically, the service establishment level determination unit 15 determines whether there is service progress information in which the "target customer ID" matches the customer ID (i) among the acquired service progress information. If there is corresponding service progress information, it means that the service has been provided to the customer by the robot 20 related to the service progress information. Otherwise, the customer is not being served (not even by robots 20 in which the customer is interested).

If the customer is receiving services from any of the robots 20 (No in S246), the process proceeds to step S255. If the customer has not received service from any robot 20 (Yes in S246), the service establishment level determination unit 15 determines the j-th robot ID from the customer information (i) (hereinafter referred to as "robot ID (j )”) is acquired (S247).

Subsequently, the service establishment level determination unit 15 determines whether or not there is a record corresponding to the customer ID (i) and the robot ID (j) in the survey DB 124 (S248).

FIG. 21 is a diagram showing a configuration example of the survey DB 124. As shown in FIG. As shown in FIG. 21, each record of the survey DB 124 includes "customer ID", "robot ID", "survey start date and time", "survey end date and time", "service delivery/reception failure flag", and "non-contact interest value". , “contact interest value”, “body expression interest value”, “voice interaction interest value”, “UI access interest value”, “body action value”, “voice action value”, “information presentation action value” and “hands-free Including items such as "value".

"Customer ID" is the customer ID of the customer corresponding to the record. "Robot ID" is the robot ID of the robot 20 corresponding to the record. The "investigation start date and time" is the start date and time of the investigation on the investigation results (items after the "service transfer failure flag") stored in the record. The “survey end date and time” is the end date and time of the survey related to the survey result stored in the record.

The "service delivery/reception failure flag" is a flag indicating whether or not the customer associated with the "customer ID" appears after the robot 20 associated with the "robot ID" starts the service and continues to stay in front of the robot 20. Yes, "1" or "0" is set. "1" indicates that the situation is occurring. "0" indicates that the situation has not occurred.

The "non-contact interest value" is based on the customer's interest in the robot 20 when the customer associated with the "customer ID" is not in contact with the robot 20 associated with the robot ID. is an index for evaluating the size of

The “contact interest value” is an index for evaluating the degree of interest of the customer in the robot 20 based on the contact status of the customer associated with the “customer ID” with respect to the robot 20 associated with the “robot ID”.

The "body expression interest value" is a value for the robot 20 associated with the "customer ID" based on a specific body action (for example, turning a face, waving a hand, etc.) to the robot 20 associated with the "robot ID" by the customer associated with the "customer ID". It is an index for evaluating the degree of customer interest.

"Voice interaction interest value" evaluates the degree of interest of the customer in the robot 20 based on the customer's voice interaction (for example, talking) to the robot 20 in the "robot ID" by the customer in the "customer ID". It is an index to

The “UI access interest value” is an index for evaluating the degree of interest of the customer in the robot 20 based on the access status of the customer associated with the “customer ID” to the user interface of the robot 20 associated with the “robot ID”. be. Here, the user interface is the UI device 205 of the robot 20, for example.

The "physical action value" is an index for evaluating the continuation of physical action by the robot 20 associated with the "robot ID" to the customer associated with the "customer ID".

"Voice action value" is an index for evaluating the continuation of the voice utterance to the customer of "customer ID" by the robot 20 of "robot ID".

The "information presentation action value" is an index for evaluating the status of information presentation to the customer associated with the "customer ID" by the robot 20 associated with the "robot ID". Presenting information means, for example, displaying information on the UI device 205 included in the robot 20 .

The "idle state value" is an index indicating whether or not the customer associated with the "customer ID" is in a state of idleness. The initial value of the "idle-on-hand value" is "0", and "1" is set to the "idle-on-hand value" when the idle state is estimated.

Note that, in each of the above items, the index ending with "interest value" indicates the degree of interest in the robot 20 by the customer. Hereinafter, when these indices are not distinguished, they are simply referred to as "values of interest." Also, the index ending with “action value” is an index that indicates the magnitude of the action of the robot 20 on the customer. Hereinafter, when these indicators are not distinguished, they are simply referred to as "action values."

In step S248, the record corresponding to the customer ID (i) and the robot ID (j) (hereinafter referred to as the "target record") refers to a record including the customer ID (i) in the "customer ID" in the survey DB 124. , robot ID (j) in "robot ID". If there is a target record (Yes in S248), the service establishment level determination unit 15 determines whether or not the "investigation end date and time" of the target record is within a predetermined time (for example, several minutes) from the current time (S249). ).

If there is no target record in step S248 (No in S248), or in step S249, if a predetermined time has passed from the "survey end date and time" of the target record to the present time (No in S249), the service establishment level determination unit 15 newly generates a record (target record) corresponding to the customer ID (i) and the robot ID (j), and stores the target record in the survey DB 124 (S250). At this time, the service establishment level determination unit 15 stores the current date and time in the "investigation start date and time" of the target record.

If No in step S249, the service establishment level determination unit 15 deletes the existing target record and then generates a new target record. If a predetermined period of time has passed from the "survey end date and time" of the existing target record to the present time, the customer associated with customer ID (i) will move once from the serviceable range of robot 20 associated with robot ID (j). It is highly likely that the customer will approach the robot 20 again after leaving. Therefore, the target record is newly generated so that the survey result of the customer's situation after the customer approaches again is stored in the survey DB 124 .

In the case of Yes in step S249, or following step S250, the service establishment level determination unit 15 determines whether the customer associated with the customer ID (i) (hereinafter referred to as "target customer") and the robot 20 associated with the robot ID (j) (hereinafter referred to as "target robot 20"), the customer status investigation process is executed (S251).

Subsequently, the service establishment level determination unit 15 stores the current date and time in the "investigation end date and time" of the target record (S252). Subsequently, the service establishment level determination unit 15 determines whether or not the value of the variable j is greater than or equal to the number of robot IDs included in the customer information (i) (S253). If the value of the variable j is less than the number (No in S253), the service establishment level determination unit 15 adds 1 to the variable j (S254), and repeats steps S244 and subsequent steps. If the value of the variable j is equal to or greater than the number (Yes in S253), the service establishment level determination unit 15 determines that the variable i is the number of pieces of customer information included in the customer list (that is, the number of pieces of customer information that any of the robots 20 can provide service to). number of customers included in the range)) (S255). If the value of the variable i is less than the number (No in S255), the service establishment level determination unit 15 adds 1 to the variable i (S256), and repeats steps S243 and subsequent steps. If the value of the variable i is equal to or greater than the number (Yes in S255), the process of FIG. 18 ends.

Next, details of step S251 will be described. 22 and 23 are flowcharts for explaining an example of the processing procedure of the customer situation investigation processing. 22 and 23, "target customer", "target robot 20", and "target record" are the target customer, target robot 20, and target record at the time of step S251 in FIG.

In step S261, the service establishment level determination unit 15 determines whether or not the target customer appears after the target robot 20 starts the service and continues to stay in front of the target robot 20. Call 220. The inquiry specifies the customer ID of the target customer. When there is a response from the interaction unit 220 of the target robot 20 indicating that the situation has occurred (Yes in S261), the service establishment level determination unit 15 sets the "service delivery/reception failure flag" of the target record to 1. (S262). When there is a response from the interaction unit 220 of the target robot 20 indicating that the situation has not occurred (No in S261), the service establishment level determination unit 15 sets the "service transfer failure flag" of the target record to 0. (S263).

Subsequently, the service establishment level determination unit 15 determines that the target customer's "standing position", "head direction", or "line of sight" is fixed in the direction of the target robot 20 for a threshold time (threshold value ≥ 10 seconds) or longer. An inquiry is made to the interaction unit 220 of the target robot 20 as to whether or not a situation has occurred (S264). When there is a response from the interaction unit 220 of the target robot 20 indicating that the situation is occurring (Yes in S264), the service establishment level determination unit 15 adds 1 to the "non-contact interest value" of the target record. (S265). In this case, it is detected that the target customer is interested in the target robot 20 .

Subsequently, the service establishment level determination unit 15 determines whether or not there is a situation in which the target customer continuously touches the target robot 20 (operation of a UI such as a touch panel or a button). Inquires to the unit 220 (S266). When there is a response from the interaction unit 220 of the target robot 20 indicating that the situation is occurring (Yes in S266), the service establishment level determination unit 15 adds 1 to the "contact interest value" of the target record. (S267). In this case, it is detected that the target customer is interested in the target robot 20 .

Subsequently, the service establishment level determination unit 15 determines whether or not the target customer continues to perform a specific physical action (for example, turning his/her face, waving his hand, etc.) toward the target robot 20. 20 of the interaction unit 220 (S268). When there is a response from the interaction unit 220 of the target robot 20 indicating that the situation is occurring (Yes in S268), the service establishment level determination unit 15 adds 1 to the "body expression interest value" of the target record. (S269). In this case, it is detected that the target customer is interested in the target robot 20 .

Subsequently, the service establishment level determination unit 15 inquires of the interaction unit 220 of the target robot 20 whether or not there is a situation in which the target customer continues voice interaction with the target robot 20 (for example, talking to the target robot 20) (S270). . When there is a response from the interaction unit 220 of the target robot 20 indicating that the situation is occurring (Yes in S270), the service establishment level determination unit 15 adds 1 to the "voice interaction interest value" of the target record. (S271). In this case, it is detected that the target customer is interested in the target robot 20 .

Next, the service establishment level determination unit 15 determines whether or not the target customer is actively accessing the user interface of the target robot 20 (for example, pressing a button multiple times). Inquires to the unit 220 (S272). When there is a response from the interaction unit 220 of the target robot 20 indicating that the situation is occurring (Yes in S272), the service establishment level determination unit 15 adds 1 to the "UI access interest value" of the target record. (S273). In this case, it is detected that the target customer is interested in the target robot 20 .

Subsequently, the service establishment level determination unit 15 inquires of the interaction unit 220 of the target robot 20 whether or not there is a situation in which the target robot 20 faces toward the target customer or gestures continuously for a time equal to or longer than a threshold (FIG. 23: S274). When there is a response from the interaction unit 220 of the target robot 20 indicating that the situation is occurring (Yes in S274), the service establishment level determination unit 15 adds 1 to the "physical action value" of the target record. (S275).

Subsequently, the service establishment level determination unit 15 inquires of the interaction unit 220 of the target robot 20 whether or not the target robot 20 continues to speak to the target customer for a time equal to or longer than the threshold (S276). When there is a response from the interaction unit 220 of the target robot 20 indicating that the situation has occurred (Yes in S276), the service establishment level determination unit 15 adds 1 to the "voice action value" of the target record. (S277).

Subsequently, the service establishment level determination unit 15 inquires of the interaction unit 220 of the target robot 20 whether or not the information presentation of the target robot 20 to the target customer continues for a time equal to or longer than the threshold (S278). When there is a response from the interaction unit 220 of the target robot 20 indicating that the situation has occurred (Yes in S278), the service establishment level determination unit 15 adds 1 to the "information presentation action value" of the target record. (S279).

Next, the service establishment level determination unit 15 inquires of the interaction unit 220 of the target robot 20 whether or not the target customer faces another person for a long time around the target robot 20 ( S280). When there is a response from the interaction unit 220 of the target robot 20 indicating that the relevant situation has not occurred (No in S280), the service establishment level determination unit 15 sets 0 to the "hand-held value" of the target record. (S281).

On the other hand, when there is a response from the interaction unit 220 of the target robot 20 indicating that the situation has occurred (Yes in S280), the service establishment level determination unit 15 determines that the target customer has spoken with the other person. An inquiry is made to the interaction unit 220 of the target robot 20 as to whether or not a continuing situation has occurred (S282). When there is a response from the interaction unit 220 of the target robot 20 indicating that the relevant situation has occurred (Yes in S282), the service establishment level determination unit 15 sets 1 to the "idle value" of the target record. (S283).

Subsequently, the service establishment level determination unit 15 calculates the sum of all interest values of the target record (S284). Subsequently, the service establishment level determination unit 15 calculates the total sum of all action values of the target record (S284). Note that a weighted sum may be calculated in calculating the sum of interest values and the sum of action values. That is, different weights may be assigned to each interest value or each action value.

Subsequently, the service establishment level determination unit 15 calculates a value obtained by dividing the sum of the action values by the sum of the interest values as the dialogue ratio value for the set of the target customer and the target robot 20 . The calculated dialogue ratio value and the sum of the action values from which the dialogue ratio value is calculated are stored in association with the target robot ID in the customer information corresponding to the target customer in the customer list (FIG. 19). . It should be noted that the dialogue ratio value increases as the action of the target robot 20 toward the target customer increases with respect to the target customer's interest in the target robot 20 . That is, the higher the probability that the target customer is receiving the service from the target robot 20, the higher the dialogue ratio value.

Next, the details of step S108 in FIG. 7 will be described. FIG. 24 is a flowchart for explaining an example of a processing procedure for specifying a customer whose service establishment level is unreasonably low.

In step S291, the service establishment level determination unit 15 substitutes 0 for the variable i. A variable i indicates the order of customer information to be processed in the customer list (FIG. 19). The i-th customer information is hereinafter referred to as "customer information (i)". A customer ID included in customer information (i) is referred to as "customer ID (i)". Further, the customer associated with the customer ID (i) is referred to as a "target customer". Subsequently, the service establishment level determination unit 15 adds 1 to the variable i (S292). Subsequently, the service establishment level determination unit 15 determines whether or not the variable i is equal to or less than the number of pieces of customer information included in the customer list (S293).

If the variable i is equal to or less than the number (Yes in S293), the service establishment level determination unit 15 acquires the sum of the dialogue ratio value and the action value associated with each robot ID included in the customer information (i). (S294). Therefore, when customer information (i) includes multiple robot IDs, the sum of multiple interaction ratio values and multiple action values is obtained. Hereinafter, the acquired dialogue ratio values will be referred to as "dialogue ratio value group", and the sum of the acquired action values will be referred to as "action value total sum group". However, when the number of robot IDs included in the customer information (i) is one, the dialog ratio value group includes one dialog ratio value, and the action value sum total group includes one action value. is.

Subsequently, the service establishment level determination unit 15 determines whether or not there is one or more dialogue ratio values exceeding the threshold in the dialogue ratio value group (S295). That is, it is determined whether or not the target customer is receiving services from any of the robots 20 .

When there is one or more dialogue ratio values exceeding the threshold in the dialogue ratio value group (that is, when it is estimated that the target customer may be receiving services from any of the robots 20) (Yes in S295) In the survey DB 124, the service establishment level determination unit 15 determines whether the "service delivery/reception failure flag" of any one of the one or more records in which the value of the "customer ID" is the customer ID (i) is 0. It is determined whether or not (S296). If the "service delivery/reception failure flag" of any record is 0 (Yes in S296), the service establishment level determination unit 15 determines whether the sum of any of the action value sums exceeds the threshold. (S297). If the sum of any of the action values exceeds the threshold (Yes in S298), the target customer is not identified as an unjust customer, and steps S292 and subsequent steps are repeated.

On the other hand, if the determination result in any of steps S295, S296, S297, or S298 is negative, the service establishment level determination unit 15 identifies the target customer as an unfair customer, and stores the customer ID (i) in the unfair customer DB 125. Additional registration is performed (S299). In this case, since the robot 20 that the target customer is interested in is providing services to other customers, there is a high possibility that the target customer has not received the service from the robot 20. is.

In step S293, when the variable i exceeds the number of pieces of customer information included in the customer list (No in S293), the processing of FIG. 24 ends.

Next, details of step S110 in FIG. 7 will be described. FIG. 25 is a flowchart for explaining an example of the processing procedure of peripheral robot identification processing.

In step S301, the peripheral robot identification unit 16 acquires a list of customer IDs (hereinafter referred to as "unjustified customer IDs") stored in the unjustified customer DB 125. FIG. Subsequently, the peripheral robot identification unit 16 acquires a list of robot IDs whose "operation status" is "in operation" (hereinafter referred to as "robot ID list") from the robot general DB 123 (FIG. 14).

Subsequently, the peripheral robot identification unit 16 substitutes 0 for the variable i (S303). The variable i is a variable indicating the order of the fraudulent customer IDs to be processed in the list of fraudulent customer IDs. Subsequently, the peripheral robot identification unit 16 adds 1 to the variable i (S304). Hereinafter, the i-th unauthorized customer ID will be referred to as "unauthorized customer ID (i)", and the customer associated with the unauthorized customer ID (i) will be referred to as "target unauthorized customer".

Subsequently, the peripheral robot identification unit 16 determines whether or not the variable i is equal to or less than the length of the list of unauthorized customer IDs (the total number of unauthorized customer IDs) (S305). If the variable i is equal to or less than the length of the list of unauthorized customer IDs (Yes in S305), the peripheral robot identification unit 16 substitutes 0 for the variable j (S306). The variable j is a variable indicating the order of robot IDs to be processed in the robot ID list. Subsequently, the peripheral robot identification unit 16 adds 1 to the variable j (S307). Hereinafter, the j-th robot ID will be referred to as "robot ID (j)", and the robot 20 associated with robot ID (j) will be referred to as "target robot 20". Subsequently, the peripheral robot identification unit 16 determines whether or not the variable j is less than or equal to the total number of robot IDs included in the robot ID list (S308).

If the variable j is equal to or less than the total number of robot IDs included in the robot ID list (Yes in S308), the peripheral robot identification unit 16 determines whether the target unjustifiable customer is included in the serviceable range of the target robot 20. Determine (S309). Such a determination is based on the latest existence interest information (FIG. 17) (hereinafter referred to as "target existence interest information") of the existence interest history information (FIG. 16) including the robot ID (i) among the integrated existence interest history information. can be based on whether or not the illegal customer ID (i) is included in the "in-range customer IDs" of . If the target unjustifiable customer is included in the serviceable range of the target robot 20 (Yes in S309), the peripheral robot identification unit 16 saves a record including the unjustifiable customer ID (i) and the robot ID (j) in the peripheral robot DB 126. (S310), and repeats steps S307 and subsequent steps.

FIG. 26 is a diagram showing a configuration example of the peripheral robot DB 126. As shown in FIG. As shown in FIG. 26, the record of the peripheral robot DB 126 has items such as "improper customer ID", "peripheral robot ID", and "necessity of movement". "Unauthorized customer ID" is the customer ID of an unauthorized customer. The "peripheral robot ID" is the robot ID of the robot 20 that includes the unfair customer associated with the "unfair customer ID" in the serviceable range, or the unfair customer can be included in the serviceable range within a predetermined time if moved. This is the robot ID of the unique robot 20 . “Necessary to move” is an item indicating whether or not to move (“necessary”) or not (“unnecessary”) in order to include the unjust customer in the serviceable range. The value set in the "necessity of movement" for the record stored in step S310 is "unnecessary".

On the other hand, if the target unfair customer is not included in the serviceable range of the target robot 20 (No in S309), the peripheral robot identifying unit 16 determines whether the target unfair customer is detected within the threshold time if the target robot 20 moves at a predetermined speed. can be included in the serviceable range of the target robot 20 (S311). Such a determination can be made by comparing a value obtained by dividing the distance corresponding to the target unfair customer ID by a predetermined speed in the "range presence distance" of the target presence interest information (FIG. 17) and the threshold time. It is possible.

If the target robot 20 cannot include the target unfair customer in the serviceable range of the target robot 20 (No in S311), step S307 and subsequent steps are repeated. If the target robot 20 can include the target unfair customer in the serviceable range of the target robot 20 (Yes in S311), the peripheral robot identification unit 16 identifies the unfair customer ID (i) and the robot ID (j). A record is stored in the peripheral robot DB 126 (S312), and steps S307 and subsequent steps are repeated.

In step S308, when the variable j exceeds the total number of robot IDs included in the robot ID list (No in S308), step S304 and subsequent steps are repeated. In step S305, when the variable i exceeds the length of the list of unauthorized customer IDs (No in S305), the process of FIG. 25 ends.

Next, the details of step S112 in FIG. 7 will be described. FIG. 27 is a flowchart for explaining an example of a processing procedure of countermeasure candidate determination processing.

In step S321, the countermeasure candidate determination unit 17 reads all records of the peripheral robot DB 126 (FIG. 26). Subsequently, the countermeasure candidate determination unit 17 classifies the read record group into groups by unauthorized customer ID (groups by common unauthorized customer ID) (S322). Subsequently, the countermeasure candidate determination unit 17 substitutes 0 for the variable i (S323). A variable 0 is a variable for identifying a group (that is, an unfair customer) by unauthorized customer ID.

Subsequently, the countermeasure candidate determination unit 17 adds 1 to the variable i (S324). Subsequently, the countermeasure candidate determination unit 17 determines whether or not the variable i is equal to or less than the number of groups by unauthorized customer ID (S325). If the variable i is equal to or less than the number of groups (Yes in S325), the countermeasure candidate determination unit 17 selects the i-th group (hereinafter referred to as "target group") from each robot 20 associated with each robot ID. , the service progress information (FIG. 20) is acquired (S326). That is, the service progress information (FIG. 20) is acquired from each robot 20 (hereinafter referred to as "peripheral robot 20 group") around the i-th unjustified customer (hereinafter referred to as "target unjustified customer").

Subsequently, the countermeasure candidate determination unit 17 executes reserved countermeasure determination processing (S327). In the reservation countermeasure determination process, it is determined whether or not the reservation countermeasure can be implemented for the target unauthorized customer. If it is possible to implement the reserved countermeasure, robots 20 that are candidates for implementing the reserved countermeasure are identified.

FIG. 28 is a diagram for explaining a reservation countermeasure. In (1) of FIG. 28, the robot 20-1 is starting to serve customer c2, and while the robot 20-2 is starting to serve customer c3, customer c1 appears. It is shown. Here, customer c1 corresponds to the target customer.

Here, it is assumed that the robot 20-2 is currently in the core value providing state and is in the process of executing a phase with a low predictability of required time (phase 8-4 in FIG. 9). On the other hand, the remaining service time of the robot 20-1 is about 30 seconds (phase 11 in FIG. 9).

In this case, as shown in (2), the dissatisfaction of customer c1 can be resolved by causing the robot 20-1 to service customer c1 after 30 seconds have elapsed. Therefore, an example of a reservation countermeasure is to reserve the robot 20-1 to start servicing the customer c1 in 30 seconds.

Subsequently, the countermeasure candidate determination unit 17 executes piggybacking countermeasure determination processing (S328). In the piggybacking countermeasure determination process, it is determined whether or not the piggybacking countermeasure can be implemented for the target unjustifiable customer. If the piggybacking countermeasure can be implemented, the robots 20 that are candidates for implementing the piggybacking countermeasure are identified.

FIG. 29 is a diagram for explaining the piggybacking countermeasure. In FIG. 29, (1) shows a situation in which a customer c1 appears while the robot 20-1 is serving a customer c2. Customer c1 has no other choice but to watch the service of robot 20-1.

After that, as shown in (2), the robot 20-2 happened to move to the vicinity of the customer c1. about to start. Here, the customer c1 corresponds to the target customer.

In this case, as shown in (4), the dissatisfaction of the customer c1 can be resolved by allowing the customer c1 to piggyback on the service provided by the robot 20-2. Therefore, one example of the piggyback countermeasure is to make the robot 20-2 correspond not only to the customer c3 but also to the customer c1.

Subsequently, the countermeasure candidate determination unit 17 executes replacement countermeasure determination processing (S329). In the replacement countermeasure determination process, it is determined whether or not the replacement countermeasure can be implemented for the target unauthorized customer. If it is possible to implement the replacement measure, the robots 20 that are candidates for implementing the replacement measure are identified.

FIG. 30 is a diagram for explaining the replacement countermeasure. In (1) of FIG. 30, the robot 20-1 is starting to serve customer c2, and while the robot 20-2 is starting to serve customer c3, customer c1 appears. It is shown. Here, customer c1 corresponds to the target customer. The remaining time of the service by the robot 20-1 is approximately 30 seconds (for example, phase 11 in FIG. 9), and the remaining time of the service by the robot 20-2 is approximately 230 seconds (phase 8-7 in FIG. 9). to 11).

In this case, after the robot 20-1 completes the service (after 30 seconds), if the robot 20-1 performs the remaining phase (unprovided service portion) (for 200 seconds) of the robot 20-2, Robot 20-2 can be assigned to customer c1.

Therefore, as shown in (2), the robot 20-2 is replaced by the robot 20-1 to serve the customer c3, and as shown in (3), the robot 20-2 executes the service for the customer c1. is an example of a shift coping strategy.

Next, the countermeasure candidate determination unit 17 executes spot countermeasure determination processing (S330). In the spot countermeasure determination processing, it is determined whether or not spot countermeasures can be implemented for the target unauthorized customer. If it is possible to implement the spot countermeasure, the robots 20 that are candidates for implementing the spot countermeasure are identified.

FIG. 31 is a diagram for explaining measures for dealing with spots. In (1) of FIG. 31, the robot 20-1 is starting to serve customer c2, and while the robot 20-2 is starting to serve customer c3, customer c1 appears. It is shown. Here, customer c1 corresponds to the target customer. The remaining time of the service by the robot 20-1 is about 340 seconds (for example, phases 8-5 to 11 in FIG. 9), and the remaining time of the service by the robot 20-2 is about 200 seconds (for example, phases 9 to 11 in FIG. 9). In this case, since the robot 20-2 finishes the service earlier, it is desirable that the robot 20-2 should serve the customer c1. However, none of the robots 20 can respond to the customer c1 within a short period of time such as 30 seconds, so if the customer c1 is left as it is, the customer c1 may leave.

Here, it is assumed that the phase currently being executed by the robot 20-1 is the phase in which the "interaction level" is "low" (for example, phase 8-5 in FIG. 9). That is, the robot 20-1 can leave the customer c2 alone for a short period of time.

Therefore, the robot 20-1 informs the customer c1 that the robot 20-2 will start the service in 200 seconds (that is, responds to the customer c1 in a spot manner), and after 200 seconds, the robot 20-2 Starting service for c1 is an example of a spot-enabled countermeasure. If the remaining service time of each robot 20 is the opposite of the above, the robot 20-1 itself notifies (notifies) that it (robot 20-1) will start service to customer c1 in 200 seconds. ).

Subsequently, the countermeasure candidate determination unit 17 executes a countermeasure determination process for the order change spot (S331). In the order change spot countermeasure determination processing, it is determined whether or not the order change spot countermeasure countermeasure can be implemented for the target unauthorized customer. If the order change spot handling measure can be implemented, the robots 20 that are candidates for taking the order change spot handling measure are identified.

FIG. 32 is a diagram for explaining countermeasures for order change spots. In (1) of FIG. 32, the robot 20-1 has started the service for the customer c2, and the customer c1 appears while the robot 20-2 is starting the service for the customer c3. It is shown. Here, customer c1 corresponds to the target customer. The remaining time of the service by the robot 20-1 is about 380 seconds (for example, phases 8-4 to 11 in FIG. 9), and the remaining time of the service by the robot 20-2 is about 200 seconds (for example, phases 9 to 11 in FIG. 9).

Here, the phase currently being executed by the robot 20-1 is a phase whose order can be changed (for example, phase 8-4 in FIG. 9). Suppose a phase (eg, phase 8-5 in FIG. 9) is executable. As a result, the robot 20-1 can leave the customer c2 alone for a short time.

Therefore, the robot 20-1 informs the customer c1 that the robot 20-2 will start the service in 200 seconds (that is, changes the phase execution order to respond to the customer c1 in a spot manner). Seconds later, the robot 20-2 starts serving customer c1, which is an example of a spot response measure.

When step S326 and subsequent steps are executed for all groups by unauthorized customer ID (No in S325), the processing in FIG. 27 ends.

Next, details of step S327 in FIG. 27 will be described. FIG. 33 is a flow chart for explaining an example of a processing procedure of determination processing of a reservation countermeasure. In FIG. 33, the "target unfair customer", "target group", and "20 peripheral robots" are the "target unfair customer", "target group", and "20 peripheral robots" at the time of step S327 in FIG. Say.

In step S<b>341 , the countermeasure candidate determination unit 17 determines whether or not there is a robot 20 capable of completing the service within a predetermined time (for example, 60 seconds) among the surrounding robots 20 , based on the service history acquired from each robot 20 . The decision is made based on the information (FIG. 20). Specifically, the robot 20 whose "status" in the service progress information is "0" (service is not being provided), or the "average time , is determined whether there is a robot 20 within the predetermined time.

If there is one or more applicable robots 20 (Yes in S341), the countermeasure candidate determination unit 17 generates reserved countermeasure information for the applicable robot 20 (S342). The reservation countermeasure information, as shown in FIG. 34, includes items such as "type", "target customer ID", "robot ID", and "start time". The value of "type" is "reservation". "Target customer ID" is the ID of the target customer. “Robot ID” is the robot ID of the candidate robot 20 that executes the reserved countermeasure. "Start time" is the start time of the service for the target customer. If there are a plurality of applicable robots 20, the reserved countermeasure information is generated for each robot 20. FIG.

Subsequently, the countermeasure candidate determination unit 17 stores the generated reserved countermeasure information in the countermeasure candidate DB 127 (S343). It should be noted that if the corresponding robot 20 does not exist (No in S341), no reserved countermeasure information is generated.

Next, details of step S328 in FIG. 27 will be described. FIG. 35 is a flowchart for explaining an example of a processing procedure for determining a countermeasure against piggybacking. In FIG. 35, the "target unfair customer", "target group", and "20 peripheral robots" are the "target unfair customer", "target group", and "20 peripheral robots" at the time of step S328 in FIG. Say.

In step S<b>351 , the countermeasure candidate determination unit 17 determines whether or not there is a robot 20 immediately after the start of service among the surrounding robots 20 based on the service progress information ( FIG. 20 ) acquired from each robot 20 . Specifically, it may be determined whether or not there is a robot 20 whose "service start time" in the service progress information is within a predetermined time (for example, 10 seconds) from the current time. Alternatively, it may be determined whether or not there is a robot 20 whose "phase in progress" in the service progress information is a phase number up to a predetermined phase.

If there is one or more applicable robots 20 (Yes in S351), the countermeasure candidate determination unit 17 generates piggyback countermeasure information for the applicable robot 20 (S352). The piggyback countermeasure information, as shown in FIG. 34, includes items such as "type", "target customer ID", "robot ID", and "start time". The value of "type" is "piggyback". "Target customer ID" is the ID of the target customer. The “robot ID” is the robot ID of the candidate robot 20 that will perform the service for the customer associated with the “target customer ID”. "Start Time" is 0. This is because the service to the target customer is started immediately. Note that if there are a plurality of applicable robots 20 , piggybacking countermeasure information is generated for each robot 20 .

Next, the countermeasure candidate determination unit 17 stores the generated piggyback countermeasure information in the countermeasure candidate DB 127 (S353). It should be noted that if the corresponding robot 20 does not exist (No in S351), the piggybacking countermeasure information is not generated.

Next, details of step S329 in FIG. 27 will be described. FIG. 36 is a flowchart for explaining an example of a processing procedure for determining a replacement countermeasure. In FIG. 36, the "target unfair customer", "target group", and "20 peripheral robots" correspond to the "target unfair customer", "target group", and "20 peripheral robots" at the time of step S329 in FIG. Say.

In step S361, the coping measure candidate determination unit 17 determines whether or not there is a robot 20 (hereinafter referred to as "robot A") whose service is likely to end within a predetermined time (for example, within several tens of seconds) among the peripheral robots 20 group. judge. The presence or absence of robot A can be determined based on service progress information (FIG. 20) acquired from each robot 20 . For example, it may be determined that the robot 20 corresponds to the robot A when the "in-progress phase" of the service progress information is a phase belonging to the after-sales service state. Alternatively, it may be determined that the robot 20 corresponds to the robot A for which the total "average time" of the remaining phases specified based on the "end phase" of the service progress information is within the predetermined time.

If robot A does not exist (No in S361), the process of FIG. 36 ends. If there is one or more robots A (Yes in S361), the countermeasure candidate determination unit 17 substitutes 0 for the variable i (S362). A variable i is a variable for identifying a robot A to be processed among one or more robots A. FIG. Subsequently, the countermeasure candidate determination unit 17 adds 1 to the variable i (S363). The i-th robot A is hereinafter referred to as "robot A(i)".

Subsequently, the countermeasure candidate determination unit 17 determines whether or not the variable i is equal to or less than the number of robots A (S364). If the variable i is equal to or less than the number of robots A (Yes in S364), the countermeasure candidate determination unit 17 selects the robot 20 (hereinafter referred to as "robot B") is determined (S365). The presence or absence of robot B can be determined based on the latest presence interest information ( FIG. 17 ) acquired from each peripheral robot 20 .

If the robot B does not exist (No in S365), the countermeasure candidate determination unit 17 repeats step S363 and subsequent steps. If there is one or more robots B (Yes in S365), the countermeasure candidate determination unit 17 substitutes 0 for the variable j (S366). The variable j is a variable for identifying the robot B to be processed among the one or more robots B. FIG. Subsequently, the countermeasure candidate determination unit 17 adds 1 to the variable j (S367). Hereinafter, the j-th robot B is referred to as "robot B(j)".

Subsequently, the countermeasure candidate determination unit 17 determines whether or not the variable j is equal to or less than the number of robots B (S368). If the variable j is less than or equal to the number of robots B (Yes in S368), the countermeasure candidate determination unit 17 determines the customer (hereinafter referred to as "customer B(j)") currently being served by robot B(j). is within the serviceable range of robot A(i) (S369). The customer ID of customer B(j) can be specified based on the "target customer ID" of the service progress information acquired from robot B(j). Further, whether or not the customer B(j) exists within the serviceable range of the robot A(i) can be determined from the customer ID of the customer B(j), which is the most recent presence interest acquired from the robot A(i). It can be determined by whether or not it is included in the "customer ID within range" of the information (FIG. 17).

If the customer B(j) does not exist within the serviceable range of the robot A(i) (No in S369), the countermeasure candidate determination unit 17 repeats steps S367 and subsequent steps. If the customer B(j) exists within the serviceable range of the robot A(i) (Yes in S369), the countermeasure candidate determination unit 17 determines the robot B(i) after the service of the robot A(i) ends. The robot A(i) takes over the service j) has not provided to the customer B(j) and generates replacement countermeasure information indicating that the robot A(i) will provide the service to the target customer. As shown in FIG. 34, the replacement countermeasure information includes "type", "target customer ID", "transfer source ID", "transfer destination ID", "transfer customer ID", "transfer phase", "start time ” etc. are included.

The value of "type" is "replacement". "Target customer ID" is the customer ID of the target customer (the customer scheduled to receive the service from the robot A(i)). "Takeover source ID" is the robot ID of robot A(i). "Takeover destination ID" is the robot ID of robot B(j). "Handover customer ID" is the customer ID of customer B(i). "Takeover phase" is the phase number of the phase that robot A(i) takes over from robot B(j). This phase is, for example, the first phase among the phases in which the robot B(j) has not started the service at the scheduled end time of the service of the robot A(i). “Start time” is the start time of takeover. The start time may be, for example, a time after the scheduled end time of the service of robot A(i) at which the "takeover phase" can be started.

Subsequently, the countermeasure candidate determination unit 17 stores the generated replacement countermeasure information in the countermeasure candidate DB 127 (S371), and repeats steps S367 and subsequent steps.

In step S368, when the variable j exceeds the number of robots B (No in S368), step S363 and subsequent steps are repeated. In step S364, when the variable i exceeds the number of robots A (No in S364), the process of FIG. 36 ends.

Next, the details of step S330 in FIG. 27 will be described. FIG. 37 is a flowchart for explaining an example of a processing procedure for determination processing of countermeasures against spots. In FIG. 37, the "target unfair customer", "target group", and "20 peripheral robots" are the "target unfair customer", "target group", and "20 peripheral robots" at the time of step S330 in FIG. Say.

In step S381, the coping measure candidate determination unit 17 determines whether or not there is a robot 20 among the peripheral robots 20 that is "not required to move" and has a "low" "interactivity level" in the phase currently being implemented. (S381). "No need to move" means that the value of "need to move" in the peripheral robot DB 126 (FIG. 26) is "unnecessary". Further, whether or not the "interactive degree" of the phase currently being implemented is "low" can be identified by applying the "phase being implemented" of the service progress information (FIG. 20) to the service scenario (FIG. 9). be.

If there is one or more applicable robots 20 (Yes in S381), the countermeasure candidate determination unit 17 selects the robot 20 closest to the target customer (hereinafter referred to as "robot A") from among the applicable robots 20. do. It should be noted that the robot 20 closest to the target customer can be identified based on the latest existence/interest information acquired from each applicable robot 20 .

Subsequently, the countermeasure candidate determination unit 17 identifies the robot 20 with the shortest remaining service time (hereinafter referred to as “robot B”) from the surrounding robots 20 group (S383). The remaining service time of each robot 20 can be obtained by calculating the total "average time" of the remaining phases specified based on the "end phase" of the service progress information.

Subsequently, the countermeasure candidate determination unit 17 generates spot countermeasure information (S384). The spot countermeasure information includes, as shown in FIG. 34, "type", "target customer ID", "spot combination ID", "corresponding combination ID", "start time" and the like.

The value of "type" is "spot". "Target customer ID" is the customer ID of the target customer. "Spot combination ID" is the robot ID of robot A. That is, the "spot combination ID" is the robot ID of the robot 20 that notifies (reports) the timing of the end of the service by the robot B to the target customer. “Corresponding hand ID” is the robot ID of robot B. FIG. That is, the "corresponding role ID" is the robot ID of the robot 20 scheduled to provide the service to the target customer. “Start time” is the start time of the service for the target customer by the robot B. FIG. For example, the time obtained by adding the remaining service time +α calculated for the robot B in step S383 to the current time may be set as the start time.

Subsequently, the countermeasure candidate determination unit 17 stores the generated spot countermeasure information in the countermeasure candidate DB 127 (S385).

Next, the details of step S331 in FIG. 27 will be described. FIG. 38 is a flowchart for explaining an example of a processing procedure for determining a countermeasure for order-changed spots. In FIG. 38, the "target unfair customer", "target group", and "20 peripheral robots" are the same as the "target unfair customer", "target group", and "20 peripheral robots" at the time of step S331 in FIG. Say.

In step S391, the coping measure candidate determination unit 17 determines that, among the surrounding robots 20, "no movement is required" and the phase next to the phase currently being implemented (hereinafter simply referred to as the "next phase") is The presence or absence of the robot 20, which is a phase in which the order can be changed, is determined. The presence or absence of "no need to move" is the same as in step S381 in FIG. Whether or not the order of the next phase can be changed is determined by applying the "phase in progress" of the service progress information (Fig. 20) to the service scenario (Fig. 9) and determining the "order It can be determined based on whether or not a value is set in "possibility of change".

If there is one or more applicable robots 20 (Yes in S391), the countermeasure candidate determination unit 17 changes the order of the next phase among the applicable robots 20 group so that the "interactivity degree" becomes " It is determined whether or not there is a robot 20 whose next phase is the phase "low" (S392). The presence or absence of such a robot 20 can be determined by referring to the "interactivity level" in the service scenario (FIG. 9) for the phase scheduled to be executed next when the order of the next phase is changed.

If there is one or more applicable robots 20 (Yes in S392), the countermeasure candidate determination unit 17 determines the robot 20 (hereinafter referred to as the "Robot A") is selected (S393). The remaining time of the phase currently being implemented can be calculated by subtracting the "phase elapsed time" of the service progress information from the "average time" stored in the service scenario (Fig. 9) for the phase currently being implemented. .

Subsequently, the countermeasure candidate determination unit 17 identifies the robot 20 with the shortest remaining service time (hereinafter referred to as "robot B") from the surrounding robots 20 group (S394). Robot B can be identified by the same method as in step S383 of FIG.

Next, the countermeasure candidate determination unit 17 generates order change spot countermeasure information (S395). As shown in FIG. 34, the order change spot countermeasure information includes "type", "target customer ID", "spot combination ID", "corresponding combination ID", "start time" and the like.

The value of "type" is "reorder". "Target customer ID" is the customer ID of the target customer. "Spot combination ID" is the robot ID of robot A. “Corresponding hand ID” is the robot ID of robot B. FIG. “Start time” is the start time of the service for the target customer by the robot B. FIG. The meaning of each item of the order change spot countermeasure information is the same as that of each item of the spot countermeasure information.

Next, the details of step S114 in FIG. 7 will be described. FIG. 39 is a flowchart for explaining an example of a processing procedure of countermeasure selection processing.

In step S<b>401 , the countermeasure selection unit 18 acquires all countermeasure information groups ( FIG. 34 ) from the countermeasure candidate DB 127 . The reservation countermeasure information, the piggyback countermeasure information, the shift countermeasure information, the spot countermeasure information, and the order change spot countermeasure information shown in FIG. Therefore, in step S401, all countermeasure information determined for all unauthorized customers around which the robot 20 exists is obtained.

Next, the countermeasure selection unit 18 classifies the acquired countermeasure information group into groups by "target customer ID" (S402). That is, the countermeasure information group is classified into one or more groups so that countermeasure information having a common "target customer ID" belongs to the same group.

Next, the countermeasure selection unit 18 generates all combinations of countermeasure information when one piece of countermeasure information is selected from each group (S403). For example, if the number of groups (target customers) is M and the number of countermeasure information for group _k (k = 1, ..., M) is N _k , the number L of all combinations is as follows: is as follows.
L = _ΣNk
Subsequently, the countermeasure selection unit 18 substitutes 0 for the variable i (S404). Subsequently, the countermeasure selection unit 18 adds 1 to the variable i (S405). A variable i is a variable for identifying a combination to be processed among the L combinations. The i-th combination is hereinafter referred to as "combination (i)".

Subsequently, the countermeasure selection unit 18 determines whether or not the variable i is equal to or less than L (S406). If the variable i is equal to or less than L (Yes in S406), the countermeasure selection unit 18 determines that the robot IDs overlap (that is, the robots 20 involved in the countermeasures overlap in the countermeasure information group included in the combination (i) ) is determined (S407). If there is duplication of robot IDs in combination (i) (No in S407), the countermeasure selection unit 18 repeats step S405 and subsequent steps. This is because it is difficult for one robot 20 to be involved in (participate in) multiple countermeasures, so such a combination is excluded.

If there is no duplication of robot IDs in the combination (i) (Yes in S407), the countermeasure selection unit 18 obtains the following variables 1 to 5 for each piece of countermeasure information included in the combination (i).
Variable 1 = Total number of participating robots 20 Variable 2 = Number of robots 20 to take turns Variable 3 = Number of phase order changes Variable 4 = Total load value of each robot 20 Variable 5 = Start time Variable 1 is countermeasure information can be determined by the number of robot IDs in the Variable 2 is 0 except for replacement countermeasure information, and is 1 for replacement countermeasure information. Variable 3 is 0 except for reordered spot workaround information and is 1 for reordered spot workaround information. Variable 4 is the number of actions that the robot 20 performs in the countermeasure. In the case of the reservation countermeasure information, the number is 2 because it is necessary to notify the start of the service to the unauthorized customer and to execute the service. In the case of piggybacking countermeasure information, it is 1 because an operation of inviting a customer (unauthorized customer) other than the customer who has already started the service (notifying the start of the service) is required. In the case of replacement countermeasure information, the robot 20 associated with the "takeover source ID" needs to perform two actions: notifying (announcement) of the takeover and providing services to the unjust customer. The robot 20 has a total of 3 because it needs one action to take over the service. That is, it can be said that at least the reservation countermeasure information, the piggyback countermeasure information, and the shift countermeasure information are countermeasure information including an instruction to notify the robot 20 of the start of service provision. In the case of spot countermeasure information, the robot 20 associated with the "spot role ID" performs one action to deal with the unfair customer in a spot manner, and the robot 20 associated with the "handling role ID" performs a service to the unfair customer. 2 because we need 1 operation that provides . If it is order change spot countermeasure information, it is 3 because the robot 20 related to the "spot combination ID" further needs to change the order of the phases. Variable 5 is the progress from the current time to the "start time" for all countermeasure information.

Subsequently, the countermeasure selection unit 18 calculates a countermeasure-specific evaluation value for each piece of countermeasure information included in combination (i) as follows.
Response-specific evaluation value=w1/variable 1+w2/variable 2+w3/variable 3+w4/variable 4+w5/variable 5
However, w1, w2, w3, w4, and w5 are weighting coefficients set in advance for each variable.

Subsequently, the countermeasure selection unit 18 sums the evaluation values for each countermeasure information included in the combination (i) to calculate the combination evaluation value (i) of the combination (i) (S410), and step S405 and subsequent steps are repeated.

When step S410 is executed for all combinations (No in S406), the countermeasure selection unit 18 selects the combination with the smallest combination evaluation value as the combination of countermeasures to be implemented, and each The countermeasure information is stored in the countermeasure DB 128 (S411).

Next, the details of step S115 in FIG. 7 will be described. FIG. 40 is a flowchart for explaining an example of the processing procedure of the countermeasure output processing.

In step S<b>421 , the countermeasure output unit 19 determines whether countermeasure information is stored in the countermeasure DB 128 . If one or more pieces of countermeasure information are stored in the countermeasure DB 128 (Yes in S421), the countermeasure output unit 19 acquires any one piece of countermeasure information from the countermeasure DB 128 and uses the countermeasure information as a countermeasure. Delete from the policy DB 128 (S422). The acquired countermeasure information is hereinafter referred to as "target countermeasure information".

Subsequently, the countermeasure output unit 19 determines whether or not the "type" of the target countermeasure information is "reservation" or "piggyback" (S423). If the "type" of the target coping measure information is "reservation" or "piggybacking" (Yes in S423), the "robot ID (S424). In other words, a countermeasure instruction related to the target countermeasure information is output to the robot. At this time (when the "type" is "reservation" or "piggyback"), an instruction to notify the start of the service is also included.

If the "type" of the target coping measure information is neither "reservation" nor "piggyback" (No in S423), the coping measure output unit 19 determines whether the "type" of the target coping measure information is "replacement". (S425). If the “type” of the target coping measure information is “replacement” (Yes in S425), the coping measure output unit 19 outputs the “handover source ID” of the target coping measure information (that is, the replacement coping measure information (FIG. 34)). and the robot 20 associated with the "handover destination ID" (S426). In other words, a countermeasure instruction related to the target countermeasure information is output to the robot.

If the "type" of the target coping measure information is not "replacement" (No in S425), the coping measure output unit 19 determines whether the "type" of the target coping measure information is "spot" or "order change". Determine (S427). If the "type" of the target coping measure information is "spot" or "order change" (Yes in S427), the coping measure output unit 19 outputs the target coping measure information Target countermeasure information is transmitted to each of the robot 20 associated with the "spot combination ID" and the robot 20 associated with the "corresponding combination ID" of the countermeasure information (FIG. 34) (S428), and steps S421 and subsequent steps are repeated. In other words, a countermeasure instruction related to the target countermeasure information is output to the robot.

When the countermeasure DB 128 becomes empty (No in S421), the process of FIG. 40 ends.

Next, processing procedures executed by each robot 20 will be described. FIG. 41 is a flowchart for explaining an example of a processing procedure executed by the existence interest information generation unit 218. FIG.

In step S<b>501 , the presence interest information generation unit 218 acquires presence recognition data from the presence recognition unit 214 . The existence recognition data is a set of customer IDs of customers whose existence is currently recognized by the existence recognition unit 214 (hereinafter referred to as "existence recognition customers"). For example, the presence recognition unit 214 detects an image of a human face (hereinafter referred to as a “face image”) from an image captured by the eye camera 207 of the robot 20, thereby recognizing each customer. A customer ID is generated for each customer. However, the presence of the customer may be recognized using the human sensor 206 . The customer ID may be obtained, for example, from an IC card lent to the customer, a beacon of a terminal, or the like, or may be a feature quantity or feature extracted from image data obtained by imaging the appearance of the customer with the camera 207. It may be a quantity group or the like.

Subsequently, the presence/interest information generation unit 218 acquires presence direction data from the presence direction recognition unit 215 for each presence recognition customer whose presence is recognized by the presence recognition unit 214 (S502). The existing direction data is a vector (X, Y, Z) with the position of the robot 20 as a starting point. For example, the direction-of-existence recognition unit 215 generates direction-of-existence data by measuring the direction of the face image. However, the customer's direction may be recognized using the human sensor 206 .

Subsequently, the existence interest information generation unit 218 generates existence distance recognition information for each existence recognition customer whose existence is recognized by the existence recognition unit 214 and whose existence direction is recognized by the existence direction recognition unit 215, from the existence distance recognition unit 216. Existence distance data is acquired from the unit 216 (S503). Existence distance data is data indicating the distance from the robot 20 . For example, the presence distance recognition unit 216 may recognize the distance of each customer by comparing the size of each customer's face, body, etc. recognized from the image by the presence recognition unit 214 with a standard size. . Alternatively, if the robot 20 has a plurality of cameras 207 , the existence distance recognition unit 216 may estimate the depth distance by surveying using the parallax of the plurality of cameras 207 . Alternatively, if the robot 20 can acquire an image from a camera external to the robot 20 (for example, a camera installed on the ceiling or wall in the venue or a camera installed on another robot 20), the external The image from the camera may be used for triangulation to improve the accuracy of the customer's distance estimate.

Subsequently, the existence interest information generation unit 218 generates existence recognition customers whose existence is recognized by the existence recognition unit 214, the existence direction is recognized by the existence direction recognition unit 215, and the distance is recognized by the existence distance recognition unit 216. The direction of interest data is acquired from the direction of interest recognition unit 217 (S504). The direction of interest data is a vector (X, Y, Z) indicating the direction of interest of the customer. For example, the direction-of-interest recognizing unit 217 may recognize the direction of interest of the customer by detecting that the orientation of the customer's body or face (that is, the direction of interest) is fixed for a certain period of time.

Next, the existence interest information generation unit 218 generates the existence recognition data (customer ID), the existence direction data, the existence distance data, and the interest direction data acquired for each existence recognition customer, based on the existence distance data. data within the service-providable range and data outside the service-providable range (S505).

Subsequently, the existence interest information generation unit 218 generates existence interest information (FIG. 17) (S506). The current time is set in the "creation time" of the presence interest information. A value obtained by adding 1 to the "additional number" of the immediately preceding presence interest information is set in the "additional number". The number of customer IDs classified within the serviceable range in step S505 is set in the "number of people within range". A list of customer IDs classified within the service-providable range is set in the "customer ID within range". In the "range existence direction vector", a list is set that includes the existence direction data classified into the service-providable range in step S505 in an order corresponding to the order of the customer ID list of the "range customer ID". be. A list containing the existence distance data classified into the serviceable range in step S505 in the order corresponding to the order of the customer ID list of the "customer ID within the range" is set to the "existence distance within the range". . A list containing direction-of-interest data classified into the service-providable range in step S505 in the order corresponding to the order of the customer ID list of the "customer ID within the range" is set in the "vector of the direction of interest within the range". be.

The number of customer IDs classified as being out of the serviceable range in step S505 is set in the "outside range number". A list of customer IDs categorized as being out of the serviceable range is set in the "out-of-range customer ID" field. The "out-of-range existence direction vector" is set to a list containing the existence direction data classified as being out of the service-providable range in step S505 in an order corresponding to the order of the customer ID list of the "out-of-range customer ID". be. In the "existence distance out of range", a list containing the existence distance data classified as being out of the serviceable range in step S505 in an order corresponding to the order of the customer ID list of the "customer ID out of range" is set. . In the "out-of-range interested direction vector", a list containing the interested direction data classified as being out of the service-providable range in step S505 in an order corresponding to the order of the list of customer IDs in the "out-of-range customer ID" is set. be.

An ID of image data or the like used by the presence recognition unit 214 to recognize the presence of the customer is set in the "existence determination source data ID". An ID of image data or the like used by the presence direction recognition unit 215 to recognize the customer's presence direction is set in the "existence direction determination source data ID". An ID of image data or the like used by the existence distance recognition unit 216 to recognize the customer's distance is set in the "existence distance determination source data ID". An ID of image data or the like used by the interested direction recognizing unit 217 to recognize the customer's interested direction is set in the "interested direction determination source data ID".

Subsequently, the existence interest information generation unit 218 determines whether or not the difference between the existence interest information generated this time and the immediately preceding existence interest information (the "following number" is one before) satisfies a predetermined condition. (S507). The predetermined condition is a condition indicating that the presence interest information has significantly changed. For example, the predetermined condition is that the "in-range customer ID" has changed, or the "in-range existence direction vector", the "in-range existence distance", or the "in-range interest direction vector" has changed by a threshold value or more for each. may

If the difference does not satisfy a predetermined condition (that is, if the difference is not significant) (No in S507), the presence interest information generation unit 218 associates the presence interest information generated this time with the existing change occurrence time. It is stored in the existence interest information storage unit 253 (S508).

On the other hand, if the difference satisfies a predetermined condition (Yes in S507), the presence interest information generation unit 218 sets the current time as a new change occurrence time (S509). Subsequently, the presence interest information generation unit 218 stores the presence interest information generated this time in the presence interest information storage unit 253 in association with the change occurrence time (S510).

Subsequently, for example, after a certain period of time has passed, step S501 and subsequent steps are repeated.

FIG. 42 is a flowchart for explaining an example of a processing procedure executed by the service control unit 221. As shown in FIG.

In step S<b>521 , the service control unit 221 determines whether countermeasure information has been received from the server device 10 . When countermeasure information is received (Yes in S521), the service control unit 221 executes a countermeasure instruction process for the countermeasure information (S522). In the countermeasure instruction process, the service execution unit 222 is instructed to execute the countermeasure.

If countermeasure information has not been received (No in S522), the service control unit 221 determines whether the robot 20 is executing a service (S523). Whether or not the service is being executed may be determined based on the presence or absence of service progress information, or may be determined based on an inquiry to the service execution unit 222 .

If the service is not being executed (No in S523), the service control unit 221 determines whether or not there is a customer who is interested in the robot 20 for a period equal to or longer than the threshold within the serviceable range of the robot 20. (S524). The presence or absence of such a customer can be specified based on the history of existence interest information. For example, the service control unit 221 determines that, in the history of presence interest information from the present time to the threshold value or more in the past, the "in-range interested direction vector" continues to be in the direction of the robot 20 or within several meters around the robot 20. The presence or absence of the customer ID, which is the direction, is determined.

If there is a corresponding customer ID (Yes in S524), the service control unit 221 instructs the service execution unit 222 to execute the service for the customer ID (S525). If there is no corresponding customer ID (No in S524), the service control unit 221 repeats step S521 and subsequent steps.

Next, details of step S522 will be described. FIG. 43 is a flowchart for explaining an example of a processing procedure of countermeasure instruction processing. In FIG. 43, the countermeasure information (FIG. 34) targeted for the countermeasure output process is referred to as "target countermeasure information".

In step S531, the service control unit 221 determines whether or not the "type" of the target countermeasure information is "reservation". If the "type" of the target countermeasure information is "reservation" (Yes in S531), the service control unit 221 determines that the "start time" of the target countermeasure information (that is, the reservation countermeasure information (FIG. 34)) has arrived. (S532). During the standby time, the service execution unit 222 independently executes processing. Therefore, even if the robot 20 is providing a service to a certain customer, the provision of the service is continued. When the "start time" arrives, the service control unit 221 instructs the service execution unit 222 to execute the service for the customer related to the "target customer ID" of the target countermeasure information (S533). The instruction also corresponds to an instruction to notify the customer of the start of the service.

If the "type" of the target countermeasure information is not "reservation" (No in S531) but "piggyback" (Yes in S534), the service control unit 221 immediately (immediately) The service executing unit 222 is instructed to execute the service for the customer related to the "target customer ID" of the countermeasure information (that is, the piggyback countermeasure information (FIG. 34)) (S533). The instruction also corresponds to an instruction to notify the customer of the start of the service.

If the "type" of the target countermeasure information is neither "piggyback" (No in S534) but "replacement" (Yes in S535), the service control unit 221 determines whether the robot 20 is the takeover source. Determine (S536). Specifically, the service control unit 221 determines whether or not the robot ID of the robot 20 matches the "handover source ID" of the target countermeasure information (that is, replacement countermeasure information (FIG. 34)). . If the robot ID matches the "transfer source ID" (Yes in S536), the service control unit 221 waits until the "start time" of the target countermeasure information arrives (S537). When the "start time" arrives, the service control unit 221 designates the "handover destination ID" of the target countermeasure information and instructs the service execution unit 222 to take over the service (S538). In other words, an instruction is given to take over the currently running service to the robot 20 associated with the "takeover destination ID". Subsequently, the service control unit 221 instructs the service execution unit 222 to execute the service for the "target customer ID" of the target countermeasure information (S538). That is, after taking over, an instruction is given to provide the service to another customer.

On the other hand, if the robot ID does not match the "handover source ID" (No in S536), the service control unit 221 determines that the robot ID is not the target countermeasure information (that is, replacement countermeasure information (FIG. 34)). (S540). If the robot ID matches the "handover destination ID" (Yes in S540), the service control unit 221 waits until the "start time" of the target countermeasure information arrives (S541). When the "start time" arrives, the service control unit 221 causes the service execution unit to execute the service after the "takeover phase" (service portion not yet provided) for the "takeover customer ID" of the target countermeasure information. 222 (S542). In other words, the instruction designates the “takeover phase”.

If the "type" of the target coping measure information is not "replacement" (that is, if the "type" is "spot" or "order change") (No in S535), the service control unit 221 causes the robot 20 matches the "spot combination ID" of the target countermeasure information (S543). If the robot ID matches the "spot combination ID" (Yes in S543), the service control unit 221 determines whether or not the "type" of the target countermeasure information is "order change" (S544). ). If the "type" of the target countermeasure information is "order change" (Yes in S544), the service control unit 221 changes the phase of the service scenario currently read into the memory device 203 as the processing target by the service execution unit 222. Change the order (S545). Specifically, the order of the phase following the phase currently being executed is changed to the position set in the "order changeability" of the service scenario (FIG. 9) for the phase. By doing so, the next phase will be a phase with a low “interaction degree”.

Subsequently, the service control unit 221 waits until the phase to be executed by the service execution unit 222 shifts to the next phase (S546). When shifting to the next phase (that is, the phase with a low “interaction level”), the service control unit 221 instructs the service execution unit 222 to execute spot correspondence (S547). The instruction designates the "target customer ID" of the target countermeasure information.

On the other hand, if the "type" of the target countermeasure information is not "order change" (that is, if it is "spot") (No in S544), the service control unit 221 does not execute steps S545 and S546 immediately. step S547 is executed. In this case, the phase currently being executed by the robot 20 is a phase with a low degree of "interaction" and is suitable for spot correspondence.

On the other hand, if the robot ID does not match the "spot combination ID" of the target countermeasure information (No at S543) but matches the "corresponding combination ID" of the target countermeasure information (Yes at S548), the service control unit 221 waits until the "start time" of the target countermeasure information arrives (S549). When the "start time" arrives, the service control unit 221 instructs the service execution unit 222 to execute the service for the "target customer ID" of the target countermeasure information (S550).

Next, a processing procedure executed by the service execution unit 222 will be described. FIG. 44 is a flowchart for explaining an example of a processing procedure executed by the service execution unit 222. FIG.

While the service is not being executed, the service execution unit 222 waits for an input of a service execution instruction (S561) or a spot correspondence instruction (S562) from the service control unit 221. FIG. When a spot handling instruction is input from the service control unit 221 (Yes in S562), the service execution unit 222 executes spot handling for the customer associated with the customer ID specified in the instruction (S563). For example, the customer is notified according to the spot correspondence.

On the other hand, when a service execution instruction is input from the service control unit 221 (Yes in S561), the service execution unit 222 reads the service scenario into the memory device 203 as a processing target (S564). Subsequently, the service execution unit 222 determines whether or not a phase number is specified for the service execution instruction (S565). For example, the phase number is specified in the service execution instruction in step S542 of FIG.

If the phase number is specified (Yes in S565), the service execution unit 222 substitutes the specified phase number for the variable f (S566). If the phase number is not specified (No in S565), the service execution unit 222 substitutes the first phase number in the service scenario for the variable f (S567). Variable f is a variable that indicates the phase number of the phase being executed.

Subsequently, the service execution unit 222 generates service progress information (FIG. 20) for the newly executed service (S568). At this time, the service execution unit 222 sets "1" in the "status" of the generated service progress information, sets a new value in the "service instance ID", and sets a service execution instruction in the "target customer ID". , the current date and time is set in 'service start time', the value of variable f is set in 'executing phase', and '0' is set in 'phase elapsed time'.

Subsequently, the service execution unit 222 starts executing the f-th phase (hereinafter referred to as “phase (f)”) (S569). For example, the service execution unit 222 controls the robot 20 based on "control information" recorded in the service scenario (FIG. 9) regarding phase (f). When phase f is the first phase number, the service execution unit 222 causes the robot to notify the customer of the customer ID specified in the service execution instruction that the service has started.

During execution of phase (f) (No in S570), when a takeover instruction is input from the service control unit 221 (Yes in S571), the service execution unit 222 causes the robot 20 to perform a takeover operation (S572). For example, a message is output (informed) that the robot 20 associated with the "handover destination ID" specified in the handover instruction will take over the service to the customer to whom the service has been provided up to now. Subsequently, the service execution unit 222 deletes the service progress information (S583) and returns to step S561. Note that the handover instruction is input in step S538 of FIG. Therefore, in this case, a service execution instruction for a new customer (unauthorized customer) should be input.

Also, during the execution of phase (f) (No in S570), if a service execution instruction is input from the service control unit 221 instead of a takeover instruction (No in S571) (Yes in S573), the service execution unit 222 controls the robot 20 so that the customer associated with the customer ID specified in the execution instruction is also included in the object of service provision (S573). The process proceeds to step S578. That is, the execution instruction is an execution instruction that is input in the case of Yes in step S534 of FIG. 43 (in the case of "piggyback"). Therefore, in step S574, the customer is notified that the service will be started immediately after the start.

Also, during execution of phase (f) (No in S570), a spot correspondence instruction is input from the service control unit 221, not a takeover instruction (No in S571) nor a service execution instruction (No in S573). (Yes in S575), the spot correspondence is executed in the same manner as in step S563 (S576), the execution of phase (f) is resumed (S577), and the process proceeds to step S578.

If there is no instruction from the service control unit 221 during execution of phase (f) (No in S575), steps S578 and subsequent steps are executed.

In step S578, the service execution unit 222 determines whether or not a certain period of time (for example, a certain number of seconds) has passed since the start or the previous execution of step S579 in phase (f). When the corresponding fixed time has passed (Yes in S578), the service execution unit 222 updates the "phase elapsed time" in the service progress information (FIG. 20) (S579). That is, the "phase elapsed time" is updated at regular time intervals.

When the execution of phase (f) is completed (Yes in S570), the service execution unit 222 compares the variable f with the final phase number of the service scenario (FIG. 9) (S580). If the variable f is not the last phase number (Yes in S580), the service execution unit 222 updates the variable f to the phase number of the phase next to f (S581). Subsequently, the service execution unit 222 updates the service progress information (FIG. 20) (S582). Specifically, the service execution unit 222 adds “f−1” to “end phase”, updates “executing phase” to the value of variable f, and updates “phase elapsed time” to 0. . Subsequently, the service execution unit 222 repeats step S569 and subsequent steps.

On the other hand, if the variable f matches the last phase number of the service scenario (FIG. 9) (No in S582), the service execution unit 222 deletes the service progress information (S583) and returns to step S561.

Next, a processing procedure executed by the interaction unit 220 will be described. 45, 46, and 47 are flowcharts for explaining an example of the processing procedure executed by the interaction unit 220. FIG. In the explanations of FIGS. 45, 46 and 47, "target customer" corresponds to "target customer" in FIG.

When the interaction unit 220 receives an inquiry (inquiry of S261 in FIG. 22) from the server device 10 as to whether or not the target customer appears after the service of the robot 20 starts and continues to stay in front of the robot 20. (Yes in S601), the presence or absence of service progress information is determined (S602). If there is no service progress information (that is, if the robot 20 is not executing the service) (No in S602), the interaction unit 220 returns a response indicating that the relevant situation has not occurred (S606).

If there is service progress information (that is, if the robot 20 is executing the service) (Yes in S602), the interaction unit 220 selects "Generation time is after the "service start time" of the service progress information (FIG. 20) (FIG. 17) from the existence interest information storage unit 253 (S603).

Subsequently, the interaction unit 220 determines whether or not the inquired situation occurs based on the existence interest information group (S604). For example, the interaction unit 220 determines that the target customer appears within the service-providable range of the robot 20 at any time point from the "service start time" to the present time, and the service can be provided from the "service start time" to the present time. It is determined whether or not the object remains within the range based on the group of existence interest information acquired (S604). In the inquiry, the target customer is specified by the customer ID. Therefore, by determining whether or not the customer ID is included in the "customer ID within the range" in each of the existence interest information from any of the existence interest information to the latest existence interest information in the existence interest information group , can determine whether the queried situation occurs or not. If the customer ID is included in the "customer IDs within the range" in each existence interest information from any existence interest information to the latest existence interest information, the interaction unit 220 determines that the situation occurs. do. Otherwise, the interaction unit 220 determines that the situation has not occurred. Subsequently, the interaction unit 220 returns the determination result to the server device 10 (S605).

In addition, the interaction unit 220 detects the occurrence of a situation in which the target customer's "standing position", "head orientation", or "line of sight" is fixed in the direction of the target robot 20 for a threshold time (threshold value ≥ 10 seconds) or longer. When the inquiry about the presence (inquiry of S264 in FIG. 22) is received from the server device 10 (Yes in S611), the "generation time" in the presence interest information group associated with the customer ID of the target customer is before the threshold time from the current time. A group of existence interest information (FIG. 17) after the "service start time" up to and after is obtained from the existence interest information storage unit 253 (S612). In addition, a group of existence interest information in the same time period, which is transmitted to the server device 10 from other robots 20 whose service provision range partially overlaps with the robot 20, is also acquired from the server device 10 and processed thereafter. may be included in

Subsequently, the interaction unit 220 determines whether or not the inquired situation occurs based on the existence interest information group (S613). For example, the interaction unit 220 determines that, in all the presence interest information included in the presence interest information group, if the "in-range interest direction vector" corresponding to the target customer is within a predetermined range from the direction of the robot 20, It is determined that the situation has occurred, otherwise it is determined that the situation has not occurred. Subsequently, the interaction unit 220 returns the determination result to the server device 10 (S614).

In addition, the interaction unit 220 makes an inquiry (inquiry of S266 in FIG. 22) as to whether or not a situation in which the target customer continuously touches the target robot 20 (operation of a UI such as a touch panel or a button) occurs. When received from the server apparatus 10 (Yes in S621), the operation log group related to the target customer from the current time to the threshold time ago is acquired from the operation log storage unit 251 (S622).

FIG. 48 is a diagram showing a configuration example of the operation log storage unit 251. As shown in FIG. One row (record) in the operation log storage unit 251 corresponds to a log (operation log) corresponding to one operation of the robot 20 by the customer. Each operation log includes "date and time", "customer ID", "operation details", and the like.

“Date and time” is the date and time when the operation occurred. "Customer ID" is the customer ID of the customer who performed the operation. The "operation content" is information indicating the operated part (touch panel, button, etc.), the meaning of the operation, and the like.

In step S622, a group of operation logs whose "customer ID" is the customer ID of the target customer and whose "date and time" is from the current time to the threshold time ago is acquired.

Subsequently, the interaction unit 220 determines whether or not the inquired situation occurs based on the operation log group (S623). For example, the interaction unit 220 determines that the situation has occurred if the number of acquired operation logs is equal to or greater than a predetermined number, and otherwise determines that the situation has not occurred. Subsequently, the interaction unit 220 returns the determination result to the server device 10 (S624).

In addition, the interaction unit 220 inquires whether or not there is a situation in which the target customer continues to perform a specific body action (for example, turns his head, waves his hand, etc.) toward the robot 20 (see S268 in FIG. 22). Inquiry) is received from the server device 10 ( FIG. 46 : Yes in S631), the presence interest information group ( 17) is obtained from the presence/interest information storage unit 253 (S632). In addition, a group of existence interest information in the same time period, which is transmitted to the server device 10 from other robots 20 whose service provision range partially overlaps with the robot 20, is also acquired from the server device 10 and processed thereafter. may be included in

Subsequently, the interaction unit 220 determines whether or not there is a time period equal to or greater than the threshold in which the target customer is interested in the robot 20, within the time period from the current time to the threshold time before, based on the acquired presence/interest information group. is determined (S633). For example, the interaction unit 220 selects presence interest information (hereinafter referred to as “target The presence/absence of the relevant time period is determined based on the existence interest information.

If there is a corresponding time period (Yes in S633), the interaction unit 220 acquires data (for example, video data, etc.) related to the "interest direction determination source data ID" of each target presence interest information (S634). Subsequently, the interaction unit 220 analyzes the acquired data to determine whether or not the inquired situation (the target customer turns his head, waves his hand, etc.) occurs (S635). Subsequently, the interaction unit 220 returns the determination result to the server device 10 (S636).

On the other hand, if there is no corresponding time period in step S633 (No in S633), the interaction unit 220 returns a response indicating that the corresponding situation does not occur (S637).

Further, when the interaction unit 220 receives from the server device 10 an inquiry (inquiry at S270 in FIG. 22) as to whether or not there is a situation in which the target customer continues voice interaction (for example, talking) to the robot 20 ( Yes in S641), in steps S642 to S644, the same processing as in steps S632 to S634 is executed. Subsequently, the interaction unit 220 analyzes the acquired data to determine whether or not the inquired situation (such as the target customer talking to the customer) has occurred (S645). For example, the interaction unit 220 determines whether or not the target customer continues the voice dialogue by performing "continuity of sound pressure", "frequency of appearance of interactive language by voice recognition", "determination of utterance by mouth image", and the like. judge. Subsequently, the interaction unit 220 returns the determination result to the server device 10 (S646).

On the other hand, if there is no relevant time period in step S643 (No in S643), the interaction unit 220 returns a response indicating that the relevant situation does not occur (S647).

In addition, the interaction unit 220 makes an inquiry (inquiry of S272 in FIG. 22) as to whether or not the target customer is actively accessing the user interface of the robot 20 (for example, pressing a button multiple times). When receiving from the server device 10 (Yes in S651), the interaction unit 220 performs the same processing as steps S622 to S624 in FIG. 45 in steps S652 to S654.

Further, when the interaction unit 220 receives from the server device 10 an inquiry (inquiry of S274 in FIG. 23) as to whether or not there is a situation in which the robot 20 continues to face or gesture toward the target customer for a time equal to or longer than a threshold (inquiry of S274 in FIG. 23) ( 47: Yes in S661), the operation log group (FIG. 17) related to the target customer from the current time to the threshold time ago is acquired from the operation log storage unit 252 (S662).

FIG. 49 is a diagram showing a configuration example of the operation log storage unit 252. As shown in FIG. One row (record) in the action log storage unit 252 corresponds to a log (action log) corresponding to one action performed by the robot 20 with respect to any customer. Each operation log includes "date and time", "customer ID", "operation details", "operation time", and the like.

“Date and time” is the date and time when the action occurred. "Customer ID" is the customer ID of the customer to be operated. "Operation content" is information indicating details of the operation content. "Action time" is the duration of the action.

In step S662, a group of operation logs whose "customer ID" is the customer ID of the target customer and whose "date and time" is from the current time to the threshold time ago is acquired.

Subsequently, the interaction unit 220 determines whether or not the inquired situation occurs based on the operation log group (S663). For example, the interaction unit 220 determines that the situation occurs if the sum of the "action time" of the action log that includes "face facing" or "hand gesture" in the "action content" in the acquired action log is equal to or greater than a threshold value. Otherwise, it is determined that the situation has not occurred. Subsequently, the interaction unit 220 returns the determination result to the server device 10 (S664).

Further, when the interaction unit 220 receives from the server device 10 an inquiry (inquiry of S276 in FIG. 23) as to whether or not there is a situation in which the voice utterance of the robot 20 to the target customer continues for a time equal to or longer than the threshold (S671 Yes), the same operation log group as in step S662 is acquired from the operation log storage unit 252 (FIG. 49) (S672).

Subsequently, the interaction unit 220 determines whether or not the inquired situation occurs based on the operation log group (S673). For example, the interaction unit 220 determines that the situation has occurred if the sum of the "operation time" of the acquired operation log that includes "voice utterance" in the "operation content" is equal to or greater than a threshold value. Otherwise, it is determined that the situation has not occurred. Subsequently, the interaction unit 220 returns the determination result to the server device 10 (S674).

Further, when the interaction unit 220 receives from the server device 10 an inquiry (inquiry of S278 in FIG. 23) as to whether or not there is a situation in which the information presentation of the robot 20 to the target customer continues for a time equal to or longer than the threshold (S681 Yes), the same operation log group as in step S662 is acquired from the operation log storage unit 252 (FIG. 49) (S682).

Subsequently, the interaction unit 220 determines whether or not the inquired situation occurs based on the operation log group (S683). For example, the interaction unit 220 determines that the situation has occurred if the sum of the "operation time" of the acquired operation log that includes "information presentation" in the "operation content" is equal to or greater than a threshold value. Otherwise, it is determined that the situation has not occurred. Subsequently, the interaction unit 220 returns the determination result to the server device 10 (S684).

Further, the interaction unit 220 receives from the server device 10 an inquiry (inquiry at S280 in FIG. 23) as to whether or not the target customer faces another person for a long time around the robot 20. Then (Yes in S691), the existence interest information storage unit 253 stores the existence interest information group ( FIG. (S692). In addition, a group of existence interest information in the same time period, which is transmitted to the server device 10 from other robots 20 whose service provision range partially overlaps with the robot 20, is also acquired from the server device 10 and processed thereafter. may be included in

Subsequently, the interaction unit 220 determines whether or not the inquired situation occurs, based on the acquired existence interest information group (S693). For example, the interaction unit 220 determines whether or not the situation occurs based on the "in-range interest direction vector" corresponding to the target customer in the existence interest information group. Subsequently, the interaction unit 220 returns the determination result to the server device 10 (S694).

Further, when the interaction unit 220 receives from the server device 10 an inquiry (inquiry of S282 in FIG. 23) as to whether or not there is a situation in which the target customer continues voice conversation with another person (Yes in S701), step Similar to S692, the existence interest information group (FIG. 17) is acquired (S702).

Subsequently, the interaction unit 220 determines whether or not the inquired situation occurs based on the acquired existence interest information group (S703). For example, the interaction unit 220 performs the same determination as in step S693, and if it is determined in the determination that the target customer faces another person for a long time, each presence interest information group By analyzing the moving image data related to the "interest direction determination source data ID" of the interest information, it is determined whether or not there is voice interaction by the target customer. Subsequently, the interaction unit 220 returns the determination result to the server device 10 (S704).

FIG. 50 is a flow chart for explaining an example of a processing procedure executed by the position measurement unit 212. As shown in FIG.

The position measurement unit 212 waits for an inquiry about GPS coordinates from the server device 10 (S801). For example, upon receiving an inquiry about GPS coordinates transmitted from the server device 10 at the timing of S222 in FIG. 20 GPS coordinates are calculated (S802). Subsequently, the position measurement unit 212 returns the GPS coordinates to the server device 10 (S803).

As described above, according to the present embodiment, when an unauthorized customer is detected, countermeasures are generated and the countermeasures are implemented. As a result, it is possible to increase the possibility that services will be provided to unauthorized customers. Therefore, the quality of customer service by the robot 20 can be improved.

It should be noted that the process executed by the server device 10 in the present embodiment may be executed by some (for example, one) of the plurality of robots 20 or by all of the robots 20 . In this case, some of the robots 20 or all of the robots 20 may have the functional configuration of the server device 10 in FIG.

Further, in the present embodiment, an example in which the robot 20 serves customers at an exhibition hall or the like has been described. good too. For example, if one of a plurality of counters is vacant and robots 20 at other counters are dealing with a plurality of customers, the robots 20 at the vacant counters may The present embodiment may be applied to control for soliciting customers lined up at the counter.

Note that in the present embodiment, the server device 10 is an example of an information processing device. The service establishment level determination unit 15 is an example of a detection unit and a determination unit. The countermeasure candidate determination unit 17 is an example of the specifying unit, the first specifying unit, and the second specifying unit. The countermeasure output unit 19 is an example of an output unit. Presence interest information is an example of the first information. Service progress information is an example of the second information and progress information.

Although the embodiments of the present invention have been described in detail above, the present invention is not limited to such specific embodiments, and various modifications can be made within the scope of the gist of the present invention described in the claims. Transformation and change are possible.

With respect to the above description, the following items are further disclosed.
(Appendix 1)
A process of detecting a person who is interested in any one of a plurality of robots providing services in the specific area based on first information indicating the direction of interest of each person present in the specific area. When,
a process of determining whether any one of the robots is providing a service based on second information indicating whether each robot is providing a service;
If any of the robots is providing a service, a process of identifying other robots that are not providing the service among the plurality of robots based on the second information;
a process of outputting an instruction to start providing a new service to the identified other robot;
is executed by an information processing device capable of communicating with the plurality of robots.
(Appendix 2)
For robots that provide services in specific areas,
A process of detecting a person who is interested in the robot based on the first information indicating the direction of interest of each person present in the specific area;
a process of determining whether or not each robot is providing a service based on second information indicating whether or not the robot is providing a service;
If the robot is providing a service, a process of identifying another robot that is not providing the service based on the second information;
a process of outputting an instruction to start providing a new service to the identified other robot;
A control program characterized by executing
(Appendix 3)
In the outputting process, an instruction for notifying that a new service provision is started is output to the specified other robot;
A control program according to appendix 1 or 2, characterized by:
(Appendix 4)
A process of detecting a person who is interested in any one of a plurality of robots providing services in the specific area based on first information indicating the direction of interest of each person present in the specific area. When,
a process of determining whether any one of the robots is providing a service based on second information indicating whether each robot is providing a service;
If any of the robots is providing a service, a process of identifying other robots that are not providing the service among the plurality of robots based on the second information;
A process of identifying a service portion that has not been provided among the services that are being provided by any of the robots, based on the progress information regarding the provision of the services of each of the robots;
a process of outputting an instruction to start providing the identified unprovided service portion to the identified other robot;
is executed by an information processing device capable of communicating with the plurality of robots.
(Appendix 5)
For robots that provide services in specific areas,
A process of detecting a person who is interested in the robot based on the first information indicating the direction of interest of each person present in the specific area;
a process of determining whether or not each robot is providing a service based on second information indicating whether or not the robot is providing a service;
If the robot is providing a service, a process of identifying another robot that is not providing the service based on the second information;
A process of identifying a service part that has not been provided among the services being provided by the robot based on the service progress information regarding the provision of the service of each robot;
a process of outputting an instruction to start providing the identified unprovided service portion to the identified other robot;
A control program characterized by executing
(Appendix 6)
A process of detecting a person who is interested in any one of a plurality of robots providing services in the specific area based on first information indicating the direction of interest of each person present in the specific area. When,
a process of determining whether any one of the robots is providing a service based on second information indicating whether each robot is providing a service;
If any of the robots is providing a service, a process of identifying other robots that are not providing the service among the plurality of robots based on the second information;
a process of outputting an instruction to start providing a new service to the identified other robot;
is executed by an information processing device capable of communicating with the plurality of robots.
(Appendix 7)
A robot that provides services in a specific area
A process of detecting a person who is interested in the robot based on the first information indicating the direction of interest of each person present in the specific area;
a process of determining whether or not each robot is providing a service based on second information indicating whether or not the robot is providing a service;
If the robot is providing a service, a process of identifying another robot that is not providing the service based on the second information;
a process of outputting an instruction to start providing a new service to the identified other robot;
A control method characterized by executing
(Appendix 8)
A process of detecting a person who is interested in any one of a plurality of robots providing services in the specific area based on first information indicating the direction of interest of each person present in the specific area. When,
a process of determining whether any one of the robots is providing a service based on second information indicating whether each robot is providing a service;
If any of the robots is providing a service, a process of identifying other robots that are not providing the service among the plurality of robots based on the second information;
A process of identifying a service portion that has not been provided among the services that are being provided by any of the robots, based on the progress information regarding the provision of the services of each of the robots;
a process of outputting an instruction to start providing the identified unprovided service portion to the identified other robot;
is executed by an information processing device capable of communicating with the plurality of robots.
(Appendix 9)
A robot that provides services in a specific area
A process of detecting a person who is interested in the robot based on the first information indicating the direction of interest of each person present in the specific area;
a process of determining whether or not each robot is providing a service based on second information indicating whether or not the robot is providing a service;
If the robot is providing a service, a process of identifying another robot that is not providing the service based on the second information;
A process of identifying a service part that has not been provided among the services being provided by the robot based on the service progress information regarding the provision of the service of each robot;
a process of outputting an instruction to start providing the identified unprovided service portion to the identified other robot;
A control method characterized by executing
(Appendix 10)
An information processing device capable of communicating with a plurality of robots that provide services in a specific area,
a detection unit that detects a person who is interested in one of the plurality of robots based on first information indicating the direction of interest of each person present in the specific area;
a determination unit that determines whether or not any of the robots is providing a service based on second information indicating whether or not each robot is providing the service;
a specifying unit that specifies, when any one of the robots is providing a service, another robot that is not providing the service among the plurality of robots based on the second information;
an output unit that outputs an instruction to start providing a new service to the specified other robot;
An information processing device comprising:
(Appendix 11)
An information processing device capable of communicating with a plurality of robots that provide services in a specific area,
a detection unit that detects a person who is interested in one of the plurality of robots based on first information indicating the direction of interest of each person present in the specific area;
a determination unit that determines whether or not any of the robots is providing a service based on second information indicating whether or not each robot is providing the service;
a first identifying unit that, when one of the robots is providing a service, identifies another robot among the plurality of robots that is not providing the service based on the second information;
a second identifying unit that identifies a portion of the service that is being provided by one of the robots that has not yet been provided, based on the progress information regarding the provision of the service by each of the robots;
an output unit that outputs to the identified other robot an instruction to start providing the identified unprovided service portion;
An information processing device comprising:

10 Server device 11 Overall space grasping unit 12 Scenario matching unit 13 Robot position grasping unit 14 Presence interest grasping unit 15 Service availability level determining unit 16 Surrounding robot identifying unit 17 Countermeasure candidate determining unit 18 Countermeasure selecting unit 19 Countermeasure output unit 20 Robot 100 Drive device 101 Recording medium 102 Auxiliary storage device 103 Memory device 104 CPU
105 Interface device 121 Spatial information DB
122 Scenario DB
123 Robot Management DB
124 Survey DB
125 Unfair Customer Database
126 Peripheral Robot DB
127 Countermeasure Candidate DB
128 Countermeasure DB
201 CPUs
202 Auxiliary storage device 203 Memory device 204 Wireless communication device 205 UI device 206 Human sensor 207 Camera 208 Microphone 209 Speaker 210 GPS receiver 211 Scenario management unit 212 Position measurement unit 213 Operation detection unit 214 Presence recognition unit 215 Presence direction recognition unit 216 Existence distance recognition unit 217 Interest direction recognition unit 218 Existence interest information generation unit 219 Operation log generation unit 220 Interaction unit 221 Service control unit 222 Service execution unit 251 Operation log storage unit 252 Operation log storage unit 253 Existence interest information storage unit 254 Scenario storage Part B Bus

Claims (10)

A person who is interested in one of a plurality of robots having a function of providing services in the specific area is identified based on first information indicating the direction of interest of each person present in the specific area. a process to detect;
Whether any of the robots is providing a service based on second information indicating whether each of the plurality of robots is providing the service and the remaining time before the service being provided ends. A process of determining whether or not
If any of the robots is providing a service, another robot, among the plurality of robots, that is providing a service different from the service and is capable of alternately providing the service is determined from the second information. a process of identifying based on
a process of outputting an instruction to alternate the provision of the service to the identified other robot;
is executed by an information processing device capable of communicating with the plurality of robots. A robot that has the function of providing services in a specific area,
A process of detecting a person who is interested in the robot based on the first information indicating the direction of interest of each person present in the specific area;
Based on the second information indicating whether or not each robot having the function of providing service in the specific area is providing the service and the remaining time before the service being provided ends, the robot provides the service. a process of determining whether or not it is being provided;
If the robot is providing a service, a process of identifying another robot that is providing a service different from the service and that can take over the provision of the service based on the second information;
a process of outputting an instruction to alternate the provision of the service to the identified other robot;
A control program characterized by executing A person who is interested in one of a plurality of robots having a function of providing services in the specific area is identified based on first information indicating the direction of interest of each person present in the specific area. a process to detect;
a process of determining whether any one of the robots is providing a service based on second information indicating whether each of the plurality of robots is providing a service;
If any of the robots is providing a service, it is determined whether or not the elapsed time since the start of the service being provided by the robot is within a predetermined period of time, and the elapsed time is within the predetermined period of time. , a process of outputting to the robot an instruction to invite the interested person to the service being provided by the robot;
is executed by an information processing device capable of communicating with the plurality of robots. A robot that has the function of providing services in a specific area,
A process of detecting a person who is interested in the robot based on the first information indicating the direction of interest of each person present in the specific area;
a process of determining whether or not each robot having a function of providing a service in the specific area is providing a service based on second information indicating whether the robot is providing the service; ,
If the robot is providing a service, determine whether the elapsed time since the start of the service being provided by the robot is within a predetermined period of time, and if the elapsed time is within the predetermined period of time. , a process of outputting to the robot an instruction to invite the interested person to the service being provided by the robot;
A control program characterized by executing A person who is interested in one of a plurality of robots having a function of providing services in the specific area is identified based on first information indicating the direction of interest of each person present in the specific area. a process to detect;
Whether any of the robots is providing a service based on second information indicating whether each of the plurality of robots is providing the service and the remaining time before the service being provided ends. A process of determining whether or not
If any of the robots is providing a service, another robot, among the plurality of robots, that is providing a service different from the service and is capable of alternately providing the service is determined from the second information. a process of identifying based on
a process of outputting an instruction to alternate the provision of the service to the identified other robot;
is executed by an information processing device capable of communicating with the plurality of robots. A robot that has the function of providing services in a specific area,
A process of detecting a person who is interested in the robot based on the first information indicating the direction of interest of each person present in the specific area;
Based on the second information indicating whether or not each robot having the function of providing service in the specific area is providing the service and the remaining time before the service being provided ends, the robot provides the service. a process of determining whether or not it is being provided;
If the robot is providing a service, a process of identifying another robot that is providing a service different from the service and that can take over the provision of the service based on the second information;
a process of outputting an instruction to alternate the provision of the service to the identified other robot;
A control method characterized by executing A person who is interested in one of a plurality of robots having a function of providing services in the specific area is identified based on first information indicating the direction of interest of each person present in the specific area. a process to detect;
a process of determining whether any one of the robots is providing a service based on second information indicating whether each of the plurality of robots is providing a service;
If any of the robots is providing a service, it is determined whether or not the elapsed time since the start of the service being provided by the robot is within a predetermined period of time, and the elapsed time is within the predetermined period of time. , a process of outputting to the robot an instruction to invite the interested person to the service being provided by the robot;
is executed by an information processing device capable of communicating with the plurality of robots. A robot that has the function of providing services in a specific area,
A process of detecting a person who is interested in the robot based on the first information indicating the direction of interest of each person present in the specific area;
a process of determining whether or not each robot having a function of providing a service in the specific area is providing a service based on second information indicating whether the robot is providing the service; ,
If the robot is providing a service, determine whether the elapsed time since the start of the service being provided by the robot is within a predetermined period of time, and if the elapsed time is within the predetermined period of time. , a process of outputting to the robot an instruction to invite the interested person to the service being provided by the robot;
A control method characterized by executing An information processing device capable of communicating with a plurality of robots having a function of providing services in a specific area,
a detection unit that detects a person who is interested in one of the plurality of robots based on first information indicating the direction of interest of each person present in the specific area;
Whether any of the robots is providing a service based on second information indicating whether each of the plurality of robots is providing the service and the remaining time before the service being provided ends. A determination unit that determines whether or not
If any of the robots is providing a service, another robot, among the plurality of robots, that is providing a service different from the service and is capable of alternately providing the service is determined from the second information. an identification part that identifies based on
an output unit that outputs an instruction to start providing a new service to the specified other robot;
An information processing device comprising: An information processing device capable of communicating with a plurality of robots having a function of providing services in a specific area,
a detection unit that detects a person who is interested in one of the plurality of robots based on first information indicating the direction of interest of each person present in the specific area;
a determination unit that determines whether any one of the robots is providing a service based on second information indicating whether each of the plurality of robots is providing the service;
If any of the robots is providing a service, it is determined whether or not the elapsed time since the start of the service being provided by the robot is within a predetermined period of time, and the elapsed time is within the predetermined period of time. , an output unit that outputs to the robot an instruction to invite the interested person to the service being provided by the robot;
An information processing device comprising:

Images