Information processing device and program

Abstract

To enable a person handling an event that occurs to be requested with high accuracy, compared with a case where history information of conversations using a messenger application is not referred to.SOLUTION: A chat system 25 has a handling person specification processing part 252 for specifying a handling person to be requested to handle an error when the error occurs in the case that a user outside a company instructs FAX transmission from a compound machine 22 installed in the company by using a chat. The handling person specification processing part 252 extracts even schedules of users which are not reflected in schedule information with reference to conversation history information even though extracts users who currently exist in the company by referring to the schedule information, and more surely extracts users existing in the company as handling candidates. Then, it specifies a handling candidate who matches a preset handling conformity condition, such as a user near the compound machine 22 from among the handling candidates as a handling person.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an information processing device and a program. [Background technology]

[0002] "Chat" has traditionally been used as an application tool for exchanging messages in real time using a computer. In recent years, dedicated services called "business chat" have also appeared, and an increasing number of companies are adopting it as an internal communication tool instead of email.

[0003] In recent years, business chat has become a way to use devices installed in the company from outside the company. For example, with business chat, you can use the fax function of a multifunction device installed in the company to send a document to a client from home.

[0004] However, if an error occurs when using company equipment from outside the company, you will not be able to resolve the issue yourself, so you would like to ask someone in the company to resolve the error.

[0005] Conventionally, technologies have been proposed that can identify users within a company by managing the location of the user identified using beacons or the GPS of the user terminal carried by the user (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Japanese Patent Application Publication No. 2019-161303 [Patent Document 2] Japanese Patent Application Laid-Open No. 2016-212720 Summary of the Invention [Problem to be solved by the invention]

[0007] However, in the past, in order to identify the location of a potential responder who could be requested to respond to an incident that occurred in a location other than the user's location, the responder had to carry a terminal with them individually, which required capital investment if necessary.

[0008] Furthermore, even if a potential responder located at the location where the incident occurred can be identified and requested to respond to the incident, there is no guarantee that the requested responder will actually respond. As a result, it can take a lot of effort to find someone who will actually respond. In particular, in the past, even in environments where messenger apps are available, the history of conversations using the messenger app was not referenced when searching for a responder to the incident.

[0009] The present invention aims to enable a user to request a person who can handle an incident that has occurred with a higher degree of accuracy than when history information of conversations using a messenger app is not referenced. [Means for solving the problem]

[0010] The information processing device of the present invention is characterized in that it includes a processor, and when a user instructs execution of a process using a messenger app, the processor identifies a responder who is present at the location where the event occurred and who is able to respond to the event by referring to the candidate's schedule information and conversation history information using the messenger app, in response to an event that occurs at a location other than the user's location, and requests the responder to respond to the event using the messenger app.

[0011] The processor also analyzes the schedule information to extract from the candidate responders those who are expected to be at the location when the event occurs, and analyzes conversation history information using a messenger app of the candidate responders to extract as the responder those of the candidate responders who are estimated to actually be at the location when the event occurs, and identifies the extracted person as the responder.

[0012] The processor is also characterized in that it identifies the person in charge by analyzing messages related to changes to schedules that have been set in the schedule information contained in the history information and messages related to schedules that have not been set in the schedule information.

[0013] The processor is also characterized in that it identifies the person to respond after taking into consideration the degree of busyness of the candidate responder at the time of responding to the event and thereafter, which is estimated by analyzing the schedule information and the history information.

[0014] The processor is also characterized by estimating the busyness of the candidate by referring to the schedule setting status within a predetermined period from the time of responding to the event, which is included in the schedule information, and the content of the conversation within a predetermined period from the time of detecting the occurrence of the event, which is included in the history information.

[0015] The processor is also characterized in that it identifies the person to handle the user after taking into consideration the degree of friendship between the candidate and the user, which is estimated by analyzing the history information.

[0016] The processor is also characterized by estimating the degree of friendship between the candidate and the user by referring to at least one of the number of conversations with the user or the number of conversations initiated by the user contained in the historical information.

[0017] The processor is also characterized in that it records response performance information regarding the responder's performance in responding to requests, and identifies the responder after taking into consideration the responding attitude toward the event in response to the request, which is inferred from the response performance information.

[0018] The processor is also characterized in that it estimates the handling attitude of the handling candidate toward the event by referring to the number of times requests are accepted or rejected.

[0019] The program of the present invention enables a computer to implement the following functions: when a user instructs a process to be executed using a messenger app, a function to identify a responder who is present at the location where the event occurred and who is able to respond to the event by referring to the candidate's schedule information and conversation history information using the messenger app, and a function to request the responder to respond to the event using the messenger app. [Effects of the Invention]

[0020] According to the inventions described in claims 1 and 10, it is possible to request someone who can handle the incident that has occurred with a higher degree of accuracy than when the conversation history information using the messenger app is not referenced.

[0021] According to the invention described in claim 2, even if a person is scheduled to be at the location of the incident, it is not necessary to identify a person as the person to respond if, by referring to the conversation history using a messenger app, it can be assumed that the person is not at the location of the incident.

[0022] According to the invention as set forth in claim 3, it is possible to identify a person to handle a case while taking into consideration a schedule that is not reflected in the schedule information.

[0023] According to the invention as set forth in claim 4, it is possible to specify a person to handle a call by taking into consideration the busyness of the candidate callers.

[0024] According to the invention of claim 5, the busyness of the candidate can be estimated from the setting status in the schedule information and the content of the conversation.

[0025] According to the invention of claim 6, it is possible to identify a person who is likely to be asked to respond to an event as the person to respond to the event.

[0026] According to the invention of claim 7, the degree of friendship between each of the service candidates and the user can be estimated from the frequency of conversations with the user.

[0027] According to the invention of claim 8, a person who cooperates in responding to an event can be identified as a person who will respond to the event.

[0028] According to the invention of claim 9, the attitude to respond to an event can be estimated from the past record of responses to events. [Brief explanation of the drawings]

[0029] [Figure 1] 1 is a diagram showing the overall configuration of a network system using a chat system in a first embodiment. [Figure 2] FIG. 2 is a diagram illustrating an outline of a processing flow in the first embodiment. [Figure 3] 10 is a flowchart showing a responder identification process according to the first embodiment. [Figure 4] FIG. 10 is a diagram showing the overall configuration of a network system according to a fourth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0030] Hereinafter, preferred embodiments of the present invention will be described with reference to the drawings.

[0031] Embodiment 1 Figure 1 shows the overall configuration of a network system using a chat system in this embodiment. Figure 1 shows a configuration in which a PC (Personal Computer) 1 and an in-house system 2 are connected via a network 3 that includes the Internet.

[0032] The internal system 2 is a LAN (Local Area Network) system established within the offices of a certain company, while the PC 1 is an information processing device used from outside the company by employees (hereinafter referred to as "users") who use the internal system 2. The PC 1 can be realized with a conventional general-purpose hardware configuration. That is, the PC 1 is configured with a CPU, ROM, RAM, storage such as a hard disk drive (HDD), a network interface as a communication means, and a user interface including input means such as a mouse and keyboard, and display means such as a display. A chat application is installed on the PC 1, and messages are exchanged with the PC 21 used by other users via chat rooms provided by the chat system 25.

[0033] "Chat" is defined as, for example, a system for real-time conversation via the Internet, and chat system 25 provides a chat service to users who use computers on which a chat application that enables chat is installed.

[0034] Furthermore, the term "messenger app" is a general term for applications that provide messaging functions, such as exchanging text messages or messages via free IP phone calls. In this embodiment, an example will be described in which a chat app is used as the messenger app to provide the messaging function to the user, but other messenger apps that provide messaging functions may also be used.

[0035] As described above, the in-house system 2 is a LAN system established within a company. The in-house system 2 is configured by connecting a PC 21, a multifunction peripheral 22, a gateway (GW) 23, a schedule management system 24, and a chat system 25 to a LAN 26. The devices 21 to 25 can communicate with each other via the LAN 26. Note that only the components necessary for explanation are shown in FIG. 1, and other components are omitted.

[0036] PC21 is an information processing device used by a user within the company. PC21 may have the same hardware configuration as PC1. Furthermore, PC21 can also become PC1 when taken outside the company. Conversely, PC1 can also become PC21 when connected to LAN 26. Note that PC1 and PC21 will be collectively referred to as "PC" without any reference numeral when there is no need to distinguish between them.

[0037] The multifunction peripheral 22 is an example of a device used by a user. The multifunction peripheral 22 is also an example of an image forming device, and is a device with a built-in computer that realizes various functions such as printing, copying, scanning, and faxing. Since the multifunction peripheral 22 has a built-in computer, it has ROM, RAM, HDD, network interface, and an operation panel as a user interface, and also has a printer, scanner, etc. to provide various functions. The multifunction peripheral 22 in this embodiment can also be used from outside the company via the gateway 23.

[0038] The gateway 23 relays data exchanged between the in-house system 2 and external devices via the network 3. The PC 1 is an example of an external device.

[0039] The schedule management system 24 is an information processing device that manages a user's schedule. The schedule management system 24 in this embodiment can be realized by a general-purpose hardware configuration that has existed for some time, such as a server computer. That is, the schedule management system 24 is configured to include at least a CPU, ROM, RAM, storage such as an HDD, and a network interface. The schedule management performed by the schedule management system 24 may be realized by software developed in-house, or may utilize a schedule management function provided by a product such as Outlook (registered trademark), which adjusts work schedules and manages personal appointments.

[0040] As described above, the chat system 25 provides a chat service to users of PCs on which a chat application is installed. The chat system 25 is an example of an information processing device according to the present invention, and can be realized by a general-purpose hardware configuration that has existed for some time, such as a server computer. That is, the chat system 25 is configured to include at least a CPU, ROM, RAM, storage such as an HDD, and a network interface. The chat system 25 may be installed outside the company, but in this embodiment, it is included in the in-house system 2 for the convenience of using the schedule information managed by the schedule management system 24.

[0041] The chat system 25 has a conversation processing unit 251, a responder identification processing unit 252, a control unit 253, and a conversation history information storage unit 254. Note that components not used in the description of this embodiment are omitted from the drawing.

[0042] The conversation processing unit 251 performs processing related to message exchanges, so-called conversations, that occur when PC users post messages to chat rooms. The conversation processing unit 251 saves the posted messages as conversation history information in the conversation history information storage unit 254. More specifically, the conversation processing unit 251 acquires messages posted to a web page (the above-mentioned "chat room") that the chat system 25 provides as a place for exchanging messages in a specific group, and accumulates conversation history information including the contents of the acquired messages in the conversation history information storage unit 254. The conversation history information includes at least the date and time the message was posted, the poster, the content of the post (i.e., the message), and identification information of the chat room to which the message was posted.

[0043] The responder identification processing unit 252 identifies a user who responds to an event that occurs when the multifunction peripheral 22 is used outside the company as the responder of the event.

[0044] The control unit 253 controls conversations in the chat system 25 by working in cooperation with the above-mentioned components 251 and 252. The control unit 253 has a device operation control unit 2531 and an event occurrence detection unit 2532. When the content of a message using chat is an instruction to execute a process, the device operation control unit 2531 instructs the corresponding device to execute the process and receives the execution result of the process by the device in accordance with the instruction. The event occurrence detection unit 2532 constantly monitors conversations using chat rooms and detects predetermined events from the content of the messages and the posting status. In this embodiment, an error that occurs when a user uses the multifunction peripheral 22 from outside the company will be described as an example of an event to be detected.

[0045] Each of the components 251 to 253 in chat system 25 is realized by cooperative operation between a computer forming chat system 25 and a program running on a CPU installed in the computer. Also, conversation history information storage unit 254 is realized by an HDD installed in chat system 25. Alternatively, RAM or external storage means may be used via a network.

[0046] Furthermore, the programs used in the present embodiment can be provided not only by communication means, but also by being stored in a computer-readable recording medium such as a CD-ROM or USB memory. The programs provided from the communication means or recording medium are installed in a computer, and various processes are realized by the computer's CPU sequentially executing the programs.

[0047] Fig. 2 is a diagram for explaining an outline of the processing flow in this embodiment, and shows the main parts of the network system shown in Fig. 1. In Fig. 2, components corresponding to those in Fig. 1 are given the same reference numerals. First, an outline of the processing flow in this embodiment will be explained using Figs. 1 and 2.

[0048] Currently, business chat provided by chat system 25 as a tool for exchanging messages is not only for exchanging messages between users, but also for causing a device to execute a process in response to an instruction from the user to execute the process. In this embodiment, the device will be described using multifunction peripheral 22 as an example.

[0049] As shown in FIG. 2, project team members, including users outside the company, exchange messages via a chat room 31 created exclusively for the project team. Furthermore, users outside the company can use their PCs 1 to instruct the multifunction peripheral 22 to execute a fax transmission process. Specifically, the user specifies a document to be transmitted and posts a message to the chat room 31 to instruct the multifunction peripheral 22 to transmit the document by fax. The conversation processing unit 251 stores the posted message in the conversation history information storage unit 254. The conversation processing unit 251 also functions as a chatbot, interpreting the content of the posted message by performing natural language processing. When the conversation processing unit 251 determines that the message corresponds to an instruction to execute a process, the device operation control unit 2531 instructs the multifunction peripheral 22 to transmit the fax by sending information necessary for fax transmission, such as the document data to be transmitted and the destination, to the multifunction peripheral 22. The device operation control unit 2531 also receives the execution result of the fax transmission process from the multifunction peripheral 22. The execution result is either normal completion or abnormal completion, and in the case of abnormal completion, information that can identify the error that occurred is included. The conversation processing unit 251 notifies the user of PC1 that requested the processing by posting a message indicating the execution result obtained by the appliance operation control unit 2531 to the chat room 31.

[0050] Here, the user of PC1 who is outside the company instructs the execution of the process via chat room 31 for the project team to which he belongs, but he may also use a personal chat room created between him and the user of PC1, for example.

[0051] As mentioned above, when using equipment installed inside a company from outside the company, if the operation completes normally, there is no problem. However, if an error occurs, there are cases where a prompt response is required. The term "error" here does not only refer to an abnormal termination of the execution result, but also includes the case where there is no response to the execution instruction, i.e., the execution result is not notified. Furthermore, "promptly" refers to a time faster than it would take for the user who recognizes the error to go to the office and respond to the error. In this case, it is desirable to have someone inside the company respond to the error. However, just because someone is inside the company does not necessarily mean that it will be sufficient. While users inside the company could be candidates to respond to the error, in reality, it is easy to imagine that the candidate may have a schedule, such as attending a meeting.

[0052] Therefore, in this embodiment, when an error occurs at a location where the user of PC1 is located (in this example, outside the company), i.e., within the company, a user who can handle the error (referred to as a "responder" in this embodiment) from among users within the company (referred to as a "responder" in this embodiment) is identified by referencing the schedule information and conversation history information of the responder. The reason for referencing not only the schedule information but also the conversation history information is that there is a possibility that a conversation may be taking place via chat about a schedule not reflected in the schedule information. A schedule not reflected in the schedule information refers, for example, to a schedule that should be managed by the schedule management system 24 but has not yet been registered in the schedule information, or a schedule that is managed by the schedule management system 24 but has been canceled or rescheduled. Schedule changes include not only date and time but also changes in location and target individuals (e.g., participants in a meeting). In this way, in this embodiment, the user's schedule is more accurately understood by referencing the conversation history information.

[0053] Below, we will explain the process of identifying the person to respond when an error occurs when a user uses a chat app on a PC 1 located outside the company to instruct a multifunction device 22 installed inside the company to send a fax, using the flowchart shown in Figure 3.

[0054] A user of PC1 starts a chat application, opens a chat room 31, and conducts conversations with project members by posting messages in the chat room 31. A conversation processing unit 251 stores messages posted by users in a conversation history information storage unit 254, thereby keeping a history of conversations using the chat room.

[0055] The user of the PC 1 then issues a fax transmission instruction to the multifunction device 22 from outside the company by posting a message containing information necessary for fax transmission, such as the destination and the document to be sent.

[0056] The conversation processing unit 251 stores messages posted to the chat room 31 in the conversation history information storage unit 254, and also performs natural language processing on the messages to interpret the contents of the messages. If the message from the user of the PC 1 is an instruction to the multifunction peripheral 22 to send a fax, the device operation control unit 2531 instructs the multifunction peripheral 22 to send a fax (step 100). The method of issuing the instruction may be the same as before. The company of the message may also be determined by the control unit 253.

[0057] The multifunction device 22 executes the FAX transmission process in response to an instruction from the device operation control unit 2531. Then, it returns the execution result of the process to the device operation control unit 2531.

[0058] If the execution result sent from the multifunction peripheral 22 indicates that the fax transmission was successful (Y in step 110), the control unit 253 causes the conversation processing unit 251 to post a message to the chat room 31 indicating that the fax transmission was successful (step 120). This allows the user of PC1 to know that the fax transmission was successful. If the execution result sent from the multifunction peripheral 22 indicates that the fax transmission was not successful but was abnormally completed (N in step 110), it is determined whether the fax transmission was instructed from within the company or from outside the company. This can be determined, for example, by analyzing the address information of the PC that issued the instruction. Here, if the user who issued the instruction is within the company (N in step 130), the control unit 253 causes the conversation processing unit 251 to post a message to the chat room 31 indicating that the fax transmission was abnormally completed (step 140). This allows users within the company to deal with the error by, for example, referring to the error message included in the message. Incidentally, an error may occur in the case of no response, where the execution result is not returned from the multifunction device 22 even after a predetermined time has elapsed since the execution instruction was given. However, if the user is within the company, the error can be dealt with by moving to the location where the multifunction device 22 is installed.

[0059] If the user who instructed the FAX transmission is outside the company (Y in step 130), even if the user can identify the error by referring to the error message, they may not be able to resolve the issue themselves. This is especially true if the error is due to a lack of response. Therefore, if the execution result from the multifunction device 22 indicates an abnormal termination or if there is no response, the event occurrence detection unit 2532 detects that an error has occurred in response to an instruction to transmit a FAX via chat.

[0060] In this case, the responder identification processing unit 252 refers to the schedule information and conversation history information to extract users who are in the company as responder candidates (step 150). First, it is assumed that the responder candidates are users who are in the company and can refer to the display on the operation panel of the multifunction peripheral 22 and perform some operation on the multifunction peripheral 22. Therefore, the responder identification processing unit 252 refers to the schedule information to identify users who are currently in the company.

[0061] As mentioned above, there may be cases where some users have confirmed plans through chat conversations, but have not yet registered those confirmed plans in the schedule management system 24. Conversely, there may be cases where a plan that was registered in the schedule information has been canceled, but has not yet been deleted from the schedule information. In this way, there may be cases where the latest plans are not reflected in the schedule information. In other words, it can be assumed that the schedule information only provides information about people who are scheduled to be in the company.

[0062] Therefore, in this embodiment, the responder identification processing unit 252 analyzes the user's schedule not only based on the schedule information managed by the schedule management system 24, but also on the history of conversations using chat, especially messages related to schedules that are not set in the schedule information, thereby making it possible to extract, as the user from among those who are expected to be present, those users who can be estimated to be most reliably present within the company at the moment.

[0063] Here, users who are within the company are extracted because they have the potential to respond to the fax transmission error that has occurred. However, although being within the company is a prerequisite, the location of the extracted users may be further narrowed down by specifying that they are within the company. That is, in this embodiment, conditions for further narrowing down the search, in other words, response suitability conditions suitable for responding to fax transmission errors, are set in advance, and users who meet these response suitability conditions are extracted from among the users present as users suitable for responding to fax transmission errors, i.e., as those who will respond to the fax transmission error (step 160).

[0064] For example, the installation location of the multifunction peripheral 22 can be identified from device management information, etc., managed in a storage unit (not shown). Meanwhile, the location of a user within the company can also be identified from schedule information and conversation history information. Therefore, the user may not be comfortable requesting a user on the first floor to handle an error that occurred in a multifunction peripheral 22 installed on the tenth floor. Therefore, in this embodiment, a condition for limiting the location of a user within the company is set as a handling suitability condition. For example, the location of a potential handling candidate is narrowed down to a certain extent, such as the floor or room where the multifunction peripheral 22 is installed, to identify a person who can handle a fax transmission error. Alternatively, the distance from the multifunction peripheral 22 may be used. In this case, a threshold value for the distance must be set in advance to identify the person who can handle the error.

[0065] If the number of users narrowed down as described above is one (N in step 190), that user can be identified as the person who handled the fax transmission error. On the other hand, if the number of users narrowed down is multiple (Y in step 190), the person who handled the fax transmission error must be narrowed down to one (step 200). For example, this may be the user who sits closest to the multifunction device 22, or the user listed at the top of the list of handling candidates. Alternatively, the handling compatibility conditions in the embodiment described below may be used.

[0066] When one responder is identified by either method, chat system 25 generates chat room 32 for a conversation between the requester and the responder (step 210). Then, chat system 25 notifies the user of PC1 who posts a message to chat room 31 using the generated chat room 32 requesting the responder to handle the FAX transmission error (step 220).

[0067] The user of PC1 references the message posted in chat room 31 and posts a message to chat room 32 requesting a response to the fax transmission error. At this point, the user of PC1 becomes the requester for response to the error. In response to the requester's message posted in chat room 32, chat system 25 requests a responder to respond to the error. In the following explanation, the user of PC1 may be referred to as the "requester" even before the request for response to the error is made.

[0068] The responder knows that he / she has been selected as the responder and that a chat room 32 has been created between him / her and the requester, for example, by a notification displayed on the PC 21b from the chat system 25. As a result, the responder responds to the request in accordance with the request.

[0069] In this embodiment, when an outside user uses a multifunction peripheral 22 installed in the company, an event that occurs as a result of that use, such as a fax transmission error in the above example, is handled by a person selected based on the user's location within the company. Naturally, when a request is made to handle a fax transmission error, the person may decline. However, in this embodiment, by taking into consideration the user's location within the company, such as their position relative to the multifunction peripheral 22, it is possible to select a person who is in the vicinity of the multifunction peripheral 22 where the error occurred, in other words, a person who is a minor candidate for handling the fax transmission error and who requires a relatively small amount of travel. This reduces the probability of a request being declined for handling a fax transmission error.

[0070] In this embodiment, the number of responders is narrowed down to one and the responder is notified to the requester, but it is also possible to present a plurality of responders, such as the top n (n is a positive integer) people, to the requester and have the requester ultimately select one responder. This also applies to the following embodiments.

[0071] Embodiment 2 In the first embodiment, the person who will handle the fax transmission error is identified by taking into consideration the location of the candidate when the fax transmission error is confirmed. In other words, in the first embodiment, the time when the fax transmission error is detected (the "current time") is considered to be the time when the error will be handled, and the schedules of users currently in the company are referenced. However, it may take some time to handle the fax transmission error.

[0072] Therefore, in this embodiment, the person who will handle the error is identified after taking into consideration the busyness of the candidate. That is, in this embodiment, busyness is set as a response suitability condition. The "busyness" of each candidate is estimated by referring to the schedule setting status and conversation history information at the time of handling the fax transmission error and within a predetermined period from that time. In other words, while the time of handling the error in the first embodiment is the time when the fax transmission error is detected, in this embodiment, the time of handling the error is set to a time range within a predetermined period from the time of handling the fax transmission error.

[0073] The system configuration (FIG. 1) and the process for identifying the responder (FIG. 3) in this embodiment may be the same as those in embodiment 1. This embodiment differs from embodiment 1 in the specific content of the process in step 160 in the flowchart shown in FIG.

[0074] That is, when a response candidate is extracted in step 150, the responder identification processing unit 252 refers to the schedule setting status of the response candidate at the time of responding to the fax transmission error and for a predetermined period thereafter, and identifies a user who does not have any scheduled appointments as a response candidate. Also, even if it may not be set in the schedule information, if it is estimated from the conversation history information that a response candidate will have a scheduled appointment after responding to the fax transmission error, that response candidate will not be selected as a response candidate. Alternatively, if a user frequently engages in conversations via chat, it can be estimated that the user is busy with something even though it is not registered in the schedule information, so that response candidate may not be selected as a response candidate.

[0075] The length of the predetermined period does not need to be particularly limited, and may be a fixed length, or may be set according to the event that occurs. Alternatively, the chat system 25 may set the length by inquiring of the requester when executing step 160.

[0076] In this embodiment, a user who can be estimated to be busy based on schedule information, chat usage status, and conversation history information is not specified as a responder, so that a responder who can respond to a request can be selected with high accuracy. Note that in this embodiment, a threshold value for the degree of busyness must be set in advance in order to specify a responder.

[0077] Embodiment 3 Generally, when requesting someone to do something, such as responding to an error, it is easier to ask an acquaintance than a stranger. Therefore, in this embodiment, the degree of friendship between a user in the company (the above-mentioned "response candidate") and the user of PC1 (the above-mentioned "requester") is taken into consideration to identify the responder. In other words, in this embodiment, the degree of friendship is set as a response compatibility condition.

[0078] The system configuration (FIG. 1) and the process for identifying the responder (FIG. 3) in this embodiment may be the same as those in embodiment 1. This embodiment differs from embodiment 1 in the specific content of the process in step 160 in the flowchart shown in FIG.

[0079] That is, when an agent candidate is extracted in step 150, the agent identification processing unit 252 estimates the friendship level between the requester and the agent candidate by analyzing the conversation history information. The friendship level may be determined, for example, by referring to at least one of the number of conversations with the requester user and the number of conversations initiated by the requester user included within a predetermined period of the conversation history information. The higher the number of conversations, the higher the friendship level is evaluated. When both are referenced, the friendship level may be calculated using a predetermined formula that weights each. The predetermined period for accumulating the number of conversations does not need to be particularly limited. The distribution and degree of variation of conversations within the predetermined period may also be taken into consideration. For example, a candidate who has scattered conversations may be evaluated as having a higher friendship level than a candidate who has a concentrated conversation. In this way, the agent identification processing unit 252 identifies the agent candidate with the highest friendship level as the agent.

[0080] According to this embodiment, it is possible for a requester to select a user who is likely to be asked to handle an error as the person to handle the error. Note that, in this embodiment, a threshold value for the friendship level needs to be set in advance in order to identify the person to handle the error.

[0081] Embodiment 4 When a user is requested to handle an error, some users may accept the request, while others may reject the request. While this may depend on the user's current situation, such as how busy they are, it is also thought that the attitude toward the request basically depends on their personality, qualities, and the like. In other words, users who accept requests basically tend to accept requests, while users who reject requests basically tend to reject requests. Therefore, this embodiment is characterized by identifying a person to handle the request after taking into consideration the attitude toward handling errors. In other words, in this embodiment, the attitude toward handling the event is set as a handling suitability condition.

[0082] FIG. 4 is a diagram showing the overall configuration of a network system according to this embodiment. The same components as those in FIG. 1 are assigned the same reference numerals, and their descriptions are omitted. The network system according to this embodiment has a configuration in which a response record management unit 255 and a response record information storage unit 256 are added to the chat system 25 shown in FIG. 1. As described above, some responders respond to requests from requesters, while others do not. The response record management unit 255 manages the response records of such responders in response to requests. To this end, when a requester requests a responder to handle an error, the response record management unit 255 generates response record information regarding the responder's response record to the request and records it in the response record information storage unit 256. The response record information includes information on the date and time of the request, information identifying the requester and the responder, information indicating the request content, such as the content of the message and the type of event that occurred, and the responder's response status to the request, i.e., information that enables determination of whether the request was accepted or rejected. The response record management unit 255 is realized by the cooperative operation of a computer forming the chat system 25 and a program running on a CPU installed in the computer. The response record information storage unit 256 is realized by an HDD installed in the chat system 25. Alternatively, RAM or external storage means may be used via a network.

[0083] Next, the operation of this embodiment will be described. In this embodiment, when an error occurs in the FAX transmission process, the requester posts a message to the chat room 32 as described above to request the person in charge to handle the error. In response to this request, the person in charge may or may not respond to the request. The response record management unit 255 interprets the content of the message by performing natural language processing on the message posted to the chat room 32. Then, the response record management unit 255 determines whether the person in charge ultimately accepted or rejected the request, generates response record information including the determination result, and registers it in the response record information storage unit 256. The response record management unit 255 repeatedly generates and registers response record information every time an event occurs. In this way, the response record of the person in charge in response to requests from the requester is accumulated in the response record information storage unit 256.

[0084] Next, a process for identifying a person to handle an error when it occurs will be described, and this process (FIG. 3) may be the same as that in embodiment 1. In this embodiment, the specific content of the process in step 160 in the flowchart shown in FIG. 3 is different.

[0085] That is, when a response candidate is extracted in step 150, the responder identification processing unit 252 estimates the response attitude of the response candidate toward the event by analyzing the response performance information. The response attitude may be determined, for example, by referring to the number of times each response candidate accepted or rejected requests to respond to errors during a predetermined period of time in the response performance information. The predetermined period for accumulating the response evaluations is not particularly limited. Furthermore, the tendency of accepting and rejecting responses during the predetermined period, for example, the increase or decrease in the number of acceptances and rejections, may also be considered. For example, if a candidate frequently rejected requests in the past but has recently started accepting requests, the response attitude may be evaluated as good. The response attitude may be quantified, for example, by calculating the ratio of the number of acceptances to the number of requests during a predetermined period. The responder identification processing unit 252 then identifies the response candidate with the best response attitude as the response candidate.

[0086] According to this embodiment, it is possible to select a user who is likely to agree to a request from a requester to handle an error as a responder. Note that in this embodiment, in order to identify a responder, it is necessary to set a threshold value for the handling attitude in advance.

[0087] In the above embodiments, a fax transmission error has been described as an example of an event that occurs when a process execution instruction is given via chat. However, the function to be used does not necessarily have to be limited to fax transmission. Furthermore, it does not necessarily have to be limited to errors. For example, when performing maintenance by remote operation, the event may be a display on the operation panel of the multifunction device 22 or a lit or blinking indicator, and the display may be checked by a user in the company. In this case, a user familiar with the multifunction device 22 or an administrator of the multifunction device 22 may be set as a correspondence compatibility condition.

[0088] In addition, in each of the above embodiments, the location of the client is outside the company, and any location other than the client's location is inside the company. However, the location of the client does not need to be limited to this classification of inside and outside. For example, even within the same company, the location of the client may be classified as inside or outside by the floor on which the client is located, or even on the same floor, by the room in which the client is located.

[0089] In the above embodiment, location, busyness level, friendliness level, and response attitude are described as examples of response compatibility conditions, but these may be combined appropriately and priorities may be set as response compatibility conditions.

[0090] In the above embodiments, the term "processor" refers to a processor in a broad sense, and includes general-purpose processors (e.g., CPU: Central Processing Unit, etc.) and dedicated processors (e.g., GPU: Graphics Processing Unit, ASIC: Application Specific Integrated Circuit, FPGA: Field Programmable Gate Array, programmable logic device, etc.).

[0091] Furthermore, the operations of the processors in the above embodiments may not only be performed by a single processor, but may also be performed by multiple processors located at physically separate locations working together. Furthermore, the order of the operations of the processors is not limited to the order described in the above embodiments, and may be changed as appropriate. [Explanation of symbols]

[0092] 1, 21, 21a, 21b PC, 2 in-house system, 3 network, 22 multifunction printer, 23 gateway (GW), 24 schedule management system, 25 chat system, 26 LAN, 31, 32 chat room, 251 conversation processing unit, 252 responder identification processing unit, 253 control unit, 254 conversation history information storage unit, 255 response record management unit, 256 response record information storage unit, 2531 equipment operation control unit, 2532 event occurrence detection unit.

Claims

1. a processor; The processor: When a user issues a command to execute a process using a messenger app, a responder who is present at the location where the event occurred and who can respond to the event is identified by referring to the candidate's schedule information and conversation history information using the messenger app, in response to an event that has occurred at a location other than the user's location. Use a messenger app to request the responder to respond to the incident; 1. An information processing device comprising:

2. The processor: extracting, from the response candidates, a person who will be at the location when the event occurs by analyzing the schedule information; As a result of analyzing conversation history information using a messenger app of the person who is expected to be present, extracting, as a person present, a person who is expected to be actually present at the location of occurrence when responding to the incident from among the person who is expected to be present, Identifying the extracted person as the corresponding person; 2. The information processing apparatus according to claim 1, wherein:

3. The information processing device according to claim 2, characterized in that the processor identifies the responder by analyzing messages related to changes to schedules already set in the schedule information contained in the history information and messages related to schedules not set in the schedule information.

4. The information processing device according to claim 1, characterized in that the processor identifies the responder after taking into consideration the degree of busyness of the responder candidate at the time of responding to the event and thereafter, which is estimated by analyzing the schedule information and the history information.

5. The information processing device according to claim 4, characterized in that the processor estimates the busyness level of the candidate by referring to the schedule setting status within a predetermined period from the time of responding to the event contained in the schedule information and the content of the conversation within a predetermined period from the time of detecting the occurrence of the event contained in the history information.

6. The information processing device according to claim 1 , wherein the processor identifies the person to be handled by taking into consideration the degree of friendship between the candidate and the user that is estimated by analyzing the history information.

7. The information processing device described in claim 6, characterized in that the processor estimates the degree of friendship between the candidate and the user by referring to at least one of the number of conversations with the user or the number of conversations started by the user contained in the historical information.

8. The processor: Recording response performance information relating to the performance of the responder in responding to the request, Identifying the responder in consideration of the response attitude toward the event in response to the request, which is estimated from the response record information.

2. The information processing apparatus according to claim 1, wherein:

9. 9. The information processing apparatus according to claim 8, wherein the processor estimates the handling attitude of the handling candidate toward the event by referring to the number of times requests are accepted or rejected.

10. On the computer, A function to identify a responder who is present at the location where an event occurred and who can respond to the event when the user instructs the execution of a process using a messenger app, by referring to the candidate's schedule information and conversation history information using the messenger app; A function to request the responder to respond to the event using a messenger app; A program to achieve this.

Images