program

Abstract

On messaging apps, the printing bot's intervention in user-to-user conversations is suppressed based on the bot's own judgment. [Solution] A program to cause a server system to execute a determination step of determining whether to print the uploaded file or to display a query message, and a control step of causing the display means to display the query message if the determination step determines that the query message should be displayed, and controlling the display means not to display the query message if the determination step determines that the query message should not be displayed.

Description

Technical Field

[0001] The present invention relates to a server system and a program for suppressing inquiries about print proposals.

Background Art

[0002] The use of messaging apps for so-called business chats, which exchange messages between multiple user terminals through a network, has been spreading. In recent years, in such messaging apps, services using so-called bots that automatically respond to messages according to the content of messages sent by users on the messaging app have been increasing. On the other hand, with the spread of cloud services, printing devices also have a network communication function, and cloud printing services are provided in which users give printing instructions from a terminal via a network.

[0003] By linking the cloud printing service and the bot service as described above, users can give a printing instruction to a printing device in an interactive format with the bot service from a messaging app on the terminal. When printing via a print bot on a messaging app, it is convenient for the print bot to propose printing to the user.

[0004] However, the intervention of a print bot in a conversation with another user may interfere with the conversation with the other user.

[0005] In Patent Document 1, a method for suppressing such intervention is described by switching between a mode for executing a print service in response to a specific message and a mode for not executing the print service.

Prior Art Documents

Patent Documents

[0006]

Patent Document 1

[0007] However, with the existing technology, the printing bot does not proactively suggest suppressing conversations, requiring the user to specify a mode, which is inconvenient. Furthermore, the instruction to stop the bot's service itself interferes with conversations with other users. Additionally, since the bot is not waiting for print commands while the service is stopped, extra conversation is required to switch modes again, further reducing convenience.

[0008] As such, cases of unnecessary inquiries can occur not only with printing bots but also in other applications, and therefore, the present invention aims to eliminate such unnecessary inquiries. [Means for solving the problem]

[0009] To solve the above problems, the program of the present invention causes the server system to execute a detection step of detecting that a file has been uploaded, a determination step of determining whether to print the uploaded file or to display a query, and a control step of causing the display means to display the query if the determination step determines that a query should be displayed, and controlling the display means not to display the query if the determination step determines that a query should not be displayed. [Effects of the Invention]

[0010] This invention eliminates unnecessary inquiries and enables convenient inquiry processing. [Brief explanation of the drawing]

[0011] [Figure 1] A diagram showing the system configuration. [Figure 2] A diagram showing the hardware configuration of client terminals, printers, and various servers. [Figure 3] Figure showing the software configurations of the client terminal and various servers. [Figure 4] Flowchart showing an example of the processing of the bot service according to the first embodiment. [Figure 5] Flowchart showing an example of the processing of the bot service according to the first embodiment. [Figure 6] Flowchart showing an example of the processing of the bot service according to the first embodiment. [Figure 7] Flowchart showing an example of the processing of the bot service according to the first embodiment. [Figure 8] Flowchart showing an example of the processing of the bot service according to the first embodiment. [Figure 9] Flowchart showing an example of the processing of the bot service according to the second embodiment. [Figure 10] Flowchart showing an example of the processing of the bot service according to the third embodiment. [Figure 11] Flowchart showing an example of the processing of the bot service according to the third embodiment. [Figure 12] Flowchart showing an example of the processing of the bot service according to the fourth embodiment. [Figure 13] Flowchart showing an example of the processing of the bot service according to the fifth embodiment. [Figure 14] Figure showing an example of the conversation of the bot service according to the first embodiment. [Figure 15] Figure showing an example of the conversation of the bot service according to the third embodiment. [Figure 16] Figure showing an example of the conversation of the bot service according to the fourth embodiment. [Figure 17] Figure showing an example of the conversation of the bot service according to the fifth embodiment. [Figure 18] Figure showing an example of event metadata information.

Embodiments for Carrying Out the Invention

[0012] Hereinafter, embodiments for implementing the present invention will be described with reference to the drawings.

[0013] <Embodiment 1> Figure 1 shows the configuration diagram of the printing bot system in this embodiment. In the following, when a server is mentioned, it is assumed to be a single server in this embodiment, but in reality, the system may consist of multiple servers. A single server or a system consisting of multiple servers will be referred to as a server system. The message application server 101, print bot server 102, cloud print server 103, client terminal 104, and printer 105 are connected via network 106. In Figure 1, one client terminal 104 and one printer 105 are shown, but in reality, there are usually multiple. Each server may also be configured with load balancing by multiple units. Conversely, a single physical server may internally virtually perform the roles of each server. Furthermore, each server may be a cloud server located on the cloud. Network 106 is assumed to be a WAN such as the internet, but it may also be a closed environment such as a company LAN. The client terminal 104 refers to a PC, tablet, smartphone, etc., and is a terminal that is directly operated by the user. Any application software can be executed on the client terminal 104. The printer 105 is a device that actually prints onto physical paper, converting print data received via the network 106 into image data and printing it. The message application server 101 provides messaging services such as chat services to client terminals. The printbot server 102 is registered as a virtual user for the messaging service provided by the message application server 101 and sends and receives messages in the same way as a regular user. The print server 106 receives print instructions and document data from external sources, converts them into print data, and then sends the print data to the designated printer 105 to issue a print instruction. When the print server 106 is deployed in a cloud environment, it may be called a cloud print server. The timing of printing to the printer 105 can be either a push-type method where no operation on the printer 105 is required by the user, or a pull-type method where printing starts only after the user initiates a print start operation on the printer 105.

[0014] Next, the hardware configuration of each device in this embodiment of the system will be described using Figure 2.

[0015] Figure 2(a) is a block diagram showing the hardware configuration of the message application server 101. The message application server 101 comprises a storage unit 214, a control unit 211, and a network communication unit 215. The storage unit 214 refers to a non-volatile storage device such as a hard disk or SSD, which is capable of storing and rewriting digital data.

[0016] The control unit 211 consists of a CPU 212 and a memory 213, and controls the overall operation of the message application server 101. The CPU 212 loads the programs stored in the storage unit 214 into the memory 213 and executes them. The memory 213 is the main memory of the CPU 212 and is used as a work area and a temporary storage area for loading various programs. The network communication unit 215 is a device that communicates with the external network 106 and performs input and output of digital data with external servers, client terminals, etc. via the network 106.

[0017] Figure 2(b) is a block diagram showing the hardware configuration of the printbot server 102. The printbot server 102 comprises a storage unit 224, a control unit 221, and a network communication unit 225. The explanations of each are the same as those for the message application server 101, so they are omitted here.

[0018] Figure 2(c) is a block diagram showing the hardware configuration of the print server 103. The print server 103 comprises a storage unit 234, a control unit 231, and a network communication unit 235. Similarly, a detailed explanation of each component is omitted.

[0019] Figure 2(d) is a block diagram showing the hardware configuration of the client terminal 104. The client terminal 104 includes a display unit 246, an operation unit 247, a storage unit 244, a control unit 241, and a network communication unit 245. The display unit 246 is a device such as an LCD display that displays visual information to the user in real time. The operation unit 247 is a device that accepts input from the user via a keyboard or mouse. A device that combines the functions of both the display unit 246 and the operation unit 247, such as a touch panel, may also be used. The explanation of the storage unit 244, the control unit 241, and the network communication unit 245 is the same as that of the message application server 101, so it is omitted here.

[0020] Figure 2(e) is a block diagram showing the hardware configuration of printer 105. Printer 105 comprises a display unit 256, an operation unit 257, a storage unit 254, a control unit 251, a network communication unit 255, and a printing unit 258. The display unit 256 is a device that displays information to the user in real time, such as a touch panel or LEDs attached to printer 105. The operation unit 257 is a device that receives input from the user, and may include hardware keys such as a numeric keypad in addition to a touch panel. The storage unit 254 and control unit 251 are equivalent to those of message application server 101, so their explanation is omitted. The network communication unit 255 is a device that communicates with the external network 106, and its main role is to receive print data and send information about the status of printer 105, such as errors, to an external server. The printing unit 258 is a device that performs printing processing by feeding, printing, and ejecting paper from paper prepared in a cassette or tray. The printing method is not particularly limited, and can be electrophotographic or inkjet. The printing unit 258 also includes finishing devices such as a duplex unit used during paper output, stapling, and punching. In this embodiment, a single-function printer that only performs printing functions is described as an example of the printer 105, but a multi-function printer (multifunction device) that also has scanning and faxing functions may be used.

[0021] Next, the software configuration of each device in this embodiment will be described using Figure 3.

[0022] Figure 3(a) is a block diagram showing the software configuration of the client terminal 104. The messaging application 341 is a software application that serves as an interface with the user in network services such as business chat. Specifically, it receives message input from the user via the operation unit 247 and sends the message to the messaging application server 101, and it also receives file upload instructions from the user and sends the file to the messaging application server 101. Furthermore, when another user inputs a message, it receives notification from the messaging application server 101 and displays the message in real time on the display unit 246. Message types include general strings and images, as well as UI controls (GUI components) such as buttons and combo boxes sent by the printbot server 102, etc. It is also the role of the messaging application 341 to send predetermined action information to the messaging application server 101 when the user operates on a UI control. The file storage 342 is an area for saving user files provided in the storage unit 244 of the client terminal 104, where the user can save any file, including files created with other applications (not shown). The messaging service 341 has the authority to access the file storage 342.

[0023] Figure 3(b) is a block diagram showing the software configuration of the message application server 101. The messaging service 311 is a software application that provides network services such as business chat. It exchanges information with multiple client terminals 104 and printbot server 102 connected to the network 106. The messaging service 311 manages users and only exchanges information with pre-registered users and bots. This makes it possible to share confidential information through the messaging service 311. In this embodiment, these registered users and bots are called members. The messaging service 311 sends messages received from members to other members in real time. It also saves received files to the file storage 312 and notifies other members. When it receives the aforementioned action information, it sends that information to a pre-registered server (for example, the printbot server 102). The file storage 312 is an area provided within the storage unit 214 of the message application server 101. Member information managed by the messaging service 311 and various messages and files received from members are stored in the file storage 312 and used by the messaging service 311.

[0024] Figure 3(c) shows the software configuration of the printbot server 102. The bot service 321 receives messages from the messaging service 311 of the message application server 101 and performs processing according to the content of those messages. Specifically, it sends messages to the message application server 101 in cooperation with the print server 103 in response to a user's print request, and issues print instructions to the print server 103 in response to a print instruction. The file storage 322 is an area provided within the storage unit 224 of the printbot server 102. It stores print settings and preview images used by the bot service 321 (a software program deployed on the printbot server 102) when creating messages, and is used by the bot service 321.

[0025] Figure 3(d) shows the software configuration of the print server 103. The print service 331 is a service that receives print data from an external source and sends it to a registered printer (e.g., printer 105) via the network 106 for execution. The file storage 332 is an area provided within the storage unit 233 of the print server 103. The file storage 332 stores user information registered with the print service 331, information about the printers held by the user, default print settings for each user, a list of print settings, etc., and is used by the print service 331.

[0026] Next, the processing of applications and services in this embodiment will be explained using Figures 4 to 8, and Figures 14 and 18.

[0027] All the processes shown in Figure 4 are executed by the CPU 222 after the program of the bot service 321, stored in the memory 224 of the printbot server 102, is loaded into memory 223.

[0028] First, the bot service 321 monitors events sent from the message application server 101 (s401, s402). These events include file upload events. When an event occurs that is sent from the message application server 101, the bot service 321 detects the event and obtains event metadata information (Figure 18) as information about that event (s403). The bot service 321 determines whether the event is a message from a user (s404). For example, this can be determined by a specific parameter in the print metadata. For example, Figure 18 shows an example of event metadata information, where the event_type parameter indicates the event type. In this example, if the value of the event_type parameter is "message" (Figure 18(a), 1801), it indicates that it is a message from a user. If it is determined in s404 that it is a message from a user, the bot service 321 determines from the message content whether it is a user response to a bot suggestion (s405). For example, bot service 321 determines that a message is a response to a suggestion if it contains words expressing affirmation / negation such as "YES / NO" or "OK / Cancel," and an instruction to the bot if it contains specific words such as "Print it." If s405 determines that the message from the user is not a response from the user to the bot's suggestion, the process moves to s406. In s406, bot service 321 determines whether it is a "group conversation" where multiple members are talking, or an "individual conversation" where a member is talking to the bot one-on-one. Details will be described later in Figure 5. If s406 determines that it is a group conversation, bot service 321 executes the processing corresponding to a group conversation (s407). Details will be described later in Figure 6. If s406 determines that it is an individual conversation, bot service 321 executes the processing corresponding to an individual conversation (s408). Details will be described later in Figure 7. In s405, if it is determined that the user's message is a response to the bot's suggestion, the bot service 321 executes the processing corresponding to the user response (s409). Details will be described later in Figure 8.On the other hand, if it is determined in s404 that the event is not a message from the user, it is determined whether the event is a UI control operation such as "YES" or "NO" placed in the UI by the user (s410). If it is determined in s410 that the event is not a UI control operation by the user, it is determined that the event is not related to the bot service and processing of the event in the bot service is terminated. If it is determined in s410 that the event is a UI control operation by the user, the bot service 321 determines whether it is a response to the bot's suggestion (s411). For example, the bot service 321 makes this determination by checking whether an operation was performed on a specific UI control in the presented message. If it is determined in s411 that it is not a response to the bot's suggestion, it is determined that the event is not related to the bot service and processing of the event in the bot service is terminated. If it is determined in s411 that it is a response to the bot's suggestion, the bot service 321 executes processing corresponding to the user response (s409).

[0029] Figure 5 shows an example of a method for determining the context of a conversation.

[0030] Figure 5(a) shows an example where the setting of a conversation is determined by the location where the event occurred.

[0031] In the flow shown in Figure 5(a), bot service 321 determines that the event that occurred is a message from the user and not a response to a bot suggestion, and as a result, s501 begins.

[0032] First, the bot service 321 detects a parameter indicating the event occurrence location from the event metadata information (s501). Next, the bot service 321 determines the event occurrence location from the extracted parameter (s502). For example, FIG. 18 shows an example of event metadata information, and a parameter named room_type indicates the event occurrence location. The bot service 321 detects this room_type and determines whether the location where the group participates or the location where an individual user participates based on the value of the parameter (s502). In the example of FIG. 18, if the value of the room_type parameter is "group" (FIG. 18(a), 1802), it is determined as a message exchange place for the group, and as a result, the event occurrence location is determined as a group conversation place where members gather and talk (s503). Also, if the value of the room_type parameter is "individual" (FIG. 18(b), 1803), it is determined as a dedicated message exchange place for one member, and as a result, it is determined that the event occurrence location is an individual conversation place (s504). Here, the "place" means a chat room. Also, it is possible to determine whether the conversation place is a group conversation place or an individual conversation place based on the actual number of conversation members instead of the value of the parameter of the event occurrence location.

[0033] FIG. 5(b) is an example of determining the conversation place based on the number of conversation members.

[0034] The flow of FIG. 5(a) also starts with s511 as a result of the bot service 321 determining that the event generated is a message from the user.

[0035] First, bot service 321 retrieves the conversation history from the messaging application server (s511). Next, bot service 321 counts the number of users participating in the conversation, excluding bots, from the conversation history data (s512). Next, bot service 321 determines whether the counted number of users excluding bots is n or more (s513). If the number of users in s513 is n or more, bot service 321 determines that it is a group conversation (s514). If the number of users in s513 is less than n, bot service 321 determines that it is an individual conversation (s514). In the above, the judgment is usually made with n=2, but if intervention by a printing bot in the conversation is allowed for a specific small number of people, n is changed to match that specific small number of people.

[0036] Using the method described above, even if a "group" is a place for exchanging messages for conversation history, it can be used by virtually only one person or a small number of specific members, making it possible to improve the convenience of the printing bot.

[0037] Figure 6 shows an example of processing that corresponds to a group conversation by the bot service 321.

[0038] Figure 6 shows an example where processing is performed only when an explicit print command is given by the user in a group conversation.

[0039] In the flow shown in Figure 6(a), bot service 321 determines that the conversation setting is a group conversation setting, and as a result, s601 begins.

[0040] First, the bot service 321 analyzes the user message and determines whether it is an explicit instruction or not (s601). For example, this can be determined by specific parameters in the print metadata and terms in the message. For example, Figure 18 shows an example of event metadata information, where the parameter event_type indicates the event type. In this example, if the value of the event_type parameter is "mention" (Figure 18(c), 1804), it indicates that the message is addressed to a specific person. Furthermore, if the message addresses the print bot and contains terms related to printing, such as "@Print_Bot, print file xxxx" (Figure 14, 1401, Figure 18(c), 1805), it is determined to be an explicit instruction. If it is determined to be an explicit instruction in s601, the bot service 321 identifies the user who issued the instruction (s602). Next, the bot service 321 addresses the identified user and makes a suggestion to confirm the instruction (e.g., writing a message to the chat room) (s603).

[0041] Figure 6(b) shows a more specific example of the proposed implementation.

[0042] For example, bot service 321 queries print server 103 to verify user authentication, determining whether the specified user actually exists (s611). Next, bot service 321 determines user authentication based on the response from print server 103 (s612). If user authentication is successful in s612, bot service 321 obtains user-specific print environment information from print server 103 (s615). Examples of print environment information include printer ID, printer type, and default print settings. Next, bot service 321 generates a message to the user confirming the print execution (s616). For example, it generates a message such as "@User C, we will print file xxxx to printer ABC. Is that OK?" (Figures 14, 1402). At this time, to prevent an increase in unnecessary messages during the group conversation, bot service 321 creates a UI control for user responses (s617). For example, buttons such as "YES" and "NO" are created as UI controls (Figures 14, 1403). Next, the bot service 321 combines the generated message and the UI controls and sends them to the message application server 101 (s618). On the other hand, if it is determined in s612 that user authentication has failed, the bot service 321 generates a message indicating that user authentication has failed (s613). For example, it generates a message such as "User authentication failed". Then, the bot service 321 sends the generated message to the message application server 101 (s614).

[0043] Figure 7 shows an example of processing corresponding to an individual conversation by the bot service 321.

[0044] Figure 7 shows an example where bot service 321 determines that the conversation space is an individual conversation space, and in response to a file being presented (uploaded) by the user in the individual conversation space (i.e., detecting that it has been uploaded), bot service 321 makes a suggestion.

[0045] In the flow shown in Figure 7(a), the bot service 321 detects that a file has been uploaded, determines that the conversation is a private conversation, and then determines that it is not a response to a bot's suggestion, after which s701 begins.

[0046] First, bot service 321 identifies the user with whom the printing bot is having a one-on-one conversation (s701). Next, bot service 321 determines whether a file is presented (uploaded) in the conversation message (s702). If a file is presented in the message, bot service 321 suggests printing that file (s703). For example, it generates a message such as "Shall we print file oooo to printer ABC?" and sends it to message application server 102 (Figures 14, 1404). This results in the message being written to the chat room page. Figure 7(b) shows the specific flow of the suggestion implementation. However, since Figure 7(b) is the same as Figure 6(b) except for s615, the explanation is omitted. The reason why s615 is not present in Figure 7(b) is to show that, because it is a one-on-one conversation, there is no need to worry about other users, and therefore the user can respond with "YES" or "NO" using a message rather than a command. Of course, as in Figure 6(b), it is also possible to synthesize response commands within the message.

[0047] Figure 8 shows an example of how the bot service 321 processes responses from users.

[0048] Figure 8 shows an example where the bot service 321 sends a print command and file to the print server 103 in response to a user's response.

[0049] The flow in Figure 8 begins when bot service 321 determines that the occurring event is a response from the user via a message or UI control operation, and s801 starts. First, bot service 321 determines whether the user response is positive or negative (s801).

[0050] For example, if the user replies with "YES" in a message or presses the "YES" UI control button, it is judged as affirmative. Conversely, if the user replies with "NO" in a message or presses the "NO" UI control button, it is judged as negative. If it is determined to be affirmative in s801, the bot service 321 checks whether user authentication has already been performed with the print server 103. If it is determined in s802 that authentication has already been performed, the bot service 321 retrieves the file to be printed from the message application server 101 (s803). Next, the bot service 321 sends the print command and the retrieved file to the print server 103 (s804). On the other hand, if it is determined to be negative in s801, the bot service 321 does nothing. Also, if it is determined in s802 that user authentication has not been performed, user authentication is performed with the print server 103. Note that the processing from S805 to S808 is the same as the processing from S711 to S714 in Figure 7, so the explanation is omitted.

[0051] As described above, the bot service 321 can determine whether it is a group conversation or an individual conversation, and adaptively control message delivery according to the setting, thereby preventing unnecessary intervention by the bot in conversations between users. Furthermore, even when the bot service 321 is suppressing intervention in conversations, it waits for a print command, so printing can be executed immediately when a print command is received, thus preventing a decrease in convenience.

[0052] <Embodiment 2> Embodiment 1 describes an example of suppressing the printing bot's intervention in a conversation depending on the type of conversation setting.

[0053] In this embodiment, we further describe a method for switching the actions of the printing bot in response to the user's response to the suggestions from the printing bot, even in a one-on-one conversation setting.

[0054] The specific processing according to this embodiment will be explained with reference to Figure 9.

[0055] Here, we will only explain the differences from Embodiment 1. The system configuration, hardware / software configuration, and processing flows are the same as in Embodiment 1, with a few exceptions, so we will omit their explanation.

[0056] Figure 9 shows an example where, in a one-on-one conversation, bot service 321 suppresses a suggestion when the user does not respond to the previous suggestion from bot service 321.

[0057] In the flow shown in Figure 9, bot service 321 determines that the conversation setting is an individual conversation setting, and further determines that it is not a response to a bot's suggestion, and as a result, s901 begins.

[0058] The process from s901 to s902 is the same as the process from s701 to s702 in Figure 7, so the explanation is omitted.

[0059] If s902 determines that a file is presented in the message, bot service 321 determines whether the user responded to the previous print bot's suggestion or ignored it (s903). If there was a response to the previous suggestion in s903, bot service 321 again suggests printing to the user (s904). The detailed process of suggesting printing to the user at this time is the same as in Figure 7(b), so the explanation is omitted. On the other hand, if there was no response from the user to the previous print bot's suggestion in s903, bot service 321 analyzes the user message and determines whether it is an explicit instruction or not (s905). This is the same as the process in s601 in Figure 6, so the explanation is omitted. Next, if s905 determines that it is an explicit instruction, bot service 321 makes a suggestion to the user to confirm execution of the print (s904).

[0060] The detailed process for prompting the user to confirm the print execution at this time is the same as in Figure 6(b), so the explanation is omitted. On the other hand, if s905 determines that it is not an explicit instruction, the bot service 321 makes no suggestion.

[0061] As described above, according to this embodiment, in a one-on-one conversation, if the user does not respond to the previous suggestion from bot service 321, bot service 321 will automatically wait for explicit instructions and suppress suggestions from bot service 321. Therefore, it is possible to suppress suggestions from the bot according to the user's convenience.

[0062] <Embodiment 3> Embodiment 2 describes a method for switching the actions of the print bot in response to the user's response to the print bot's suggestions, even in a one-on-one conversation setting.

[0063] This embodiment describes a method for presenting a "wait" option to a suggestion from a print bot and switching to waiting for user instructions.

[0064] The specific processing according to this embodiment will be explained using Figures 10, 11, and 15.

[0065] Here, we will only explain the differences between Embodiments 1 and 2. The system configuration, hardware / software configuration, and processing flows are the same as Embodiment 1, with a few exceptions, so we will omit their explanation.

[0066] Figure 10 shows an example where, in a one-on-one conversation setting, a "wait" option is provided for suggestions from bot service 321, and if the user selects wait, bot service 321 suppresses suggestions until an explicit instruction is given.

[0067] The flow in Figure 10(a) begins when the bot service 321 determines that the conversation setting is an individual conversation setting and that it is not a response to a bot's suggestion. The process from s1001 to s1002 is the same as the process from s701 to s702 in Figure 7, so the explanation is omitted.

[0068] In s1002, if it is determined that a file is presented in the message, the bot service 321 determines whether the wait flag is ON or OFF (s1003). If the wait flag is ON, the bot service 321 determines that the user has selected the "Wait" option provided in the suggested response. If the wait flag is OFF, the bot service 321 determines that the user has not selected the "Wait" option provided in the suggested response. In s1003, if the wait flag is OFF, the bot service 321 suggests printing to the user (s1004). The detailed process of suggesting printing to the user at this time is the same as in Figure 6(b), so the explanation is omitted. However, at this time, the bot service 321 creates UI controls for user response, such as buttons like "YES", "NO", and "Wait" (s617).

[0069] Figure 10(b) shows the detailed process by which the bot service 321 suggests printing to the user.

[0070] The processing from s1011 to s1016 at this time is the same as the processing from s701 to s706 in Figure 7(b), so the explanation is omitted. In s1016, after the bot service 321 creates a message to the user suggesting printing, the bot service 321 generates a UI control for the user response (s1017). At this time, along with the usual affirmative and negative UI controls such as "YES" and "NO", a "Wait" UI control is also added (Figures 15, 1501). The bot service 321 combines the generated message and UI control and sends it to the message application server 101 (s1018). On the other hand, in s1003, if the wait flag is ON, the bot service 321 determines whether or not it is an explicit instruction from the user (s1005). This is the same as the processing in s601 in Figure 6, so the explanation is omitted. In S1005, if it is determined that it is not an explicit instruction, the bot service 321 does not make any suggestions. Furthermore, if it is determined in s1005 that this is an explicit instruction, the bot service 321 will make a suggestion to the user to confirm the execution of the print job (s1004).

[0071] Figure 10(c) shows the detailed process by which the bot service 321 proposes to the user confirmation of printing execution.

[0072] The process from s1021 to s1028 at this time is the same as the process from s611 to s618 in Figure 6(b), so the explanation is omitted.

[0073] In s1028, the generated message and UI control are combined and sent to the message application server 101, after which the bot service 321 resets the standby flag to OFF (s1029).

[0074] Figure 11 shows an example of how the bot service 321 processes responses from users.

[0075] Figure 11 shows an example of how bot service 321 handles situations where a "Wait" UI control is added to the proposal, along with the usual affirmative and negative UI controls such as "YES" and "NO".

[0076] The flow in Figure 11 begins when the bot service 321 determines that the occurring event is a response from the user via a message or UI control operation. Processes s1101 through s1108 in Figure 11 are the same as processes s801 through s808 in Figure 8, so their explanation is omitted.

[0077] If s1101 determines that the user's response type is "waiting," the bot service 321 turns on the waiting flag.

[0078] As described above, according to this embodiment, the bot service 321 presents the option "Wait" to the suggestion from the print bot and switches to waiting for instructions from the user, thereby waiting for explicit instructions and suppressing suggestions from the bot service 321.

[0079] Therefore, it becomes possible to suppress suggestions from bots according to the user's preferences.

[0080] <Embodiment 4> Embodiment 1 describes an example of suppressing the printing bot's intervention in a conversation depending on the type of conversation setting.

[0081] In this embodiment, we further describe a method in which, even in a group conversation, the printing bot makes a suggestion to the user as an exception when a file with a specific file name is presented.

[0082] The specific processing according to this embodiment will be explained with reference to Figures 12 and 16.

[0083] Here, we will only explain the differences from Embodiment 1. The system configuration, hardware / software configuration, and processing flows are the same as in Embodiment 1, with a few exceptions, so we will omit their explanation.

[0084] Figure 12 shows an example of processing corresponding to a group conversation by the bot service 321.

[0085] Figure 12 shows an example of processing not only when a user explicitly requests printing in a group conversation, but also when a file matching a specific keyword is presented.

[0086] The flow in Figure 12 begins when bot service 321 determines that the conversation setting is a group conversation setting.

[0087] The processes from s1201 to s1203 are the same as the processes from s601 to s603 in Figure 6(a), so their explanation is omitted.

[0088] In S1201, if it is determined that there is no explicit instruction, the bot service 321 determines whether the file name presented (uploaded) in the message matches a specific keyword that has been specified in advance (s1204). In S1204, if the file name presented in the message matches the specific keyword, the bot service 321 suggests printing to the user (s1203). The detailed process of suggesting printing to the user at this time is the same as in Figure 7(b), so the explanation is omitted. Figure 16 shows an example of the UI of this embodiment, which is an example where the keyword "invoice" is specified. In message 1601, the keyword does not match the file name, so the bot service 321 does not make a suggestion at this time. However, in message 1602, the keyword matches the file name, so the bot service 321 suggests printing as in 1603. On the other hand, in S1204, if the file name does not match the keyword, the bot service 321 does not make any suggestions.

[0089] As described above, according to this embodiment, even when the bot service 321 is suppressing suggestions from bots in a group conversation, it is possible to avoid missing important files by having the printing bot make suggestions for specific files.

[0090] <Embodiment 5> Embodiment 1 describes an example of suppressing the printing bot's intervention in a conversation depending on the type of conversation setting.

[0091] In this embodiment, we further describe a method by which the print bot makes suggestions to the user as an exception, even in a group conversation, under specific times / days / dates.

[0092] The specific processing according to this embodiment will be explained with reference to Figures 13 and 17.

[0093] Here, we will only explain the differences from Embodiment 1. The system configuration, hardware / software configuration, and processing flows are the same as in Embodiment 1, with a few exceptions, so we will omit their explanation.

[0094] Figure 13 shows an example of processing that corresponds to a group conversation by the bot service 321.

[0095] Figure 13 shows an example of processing not only when a user explicitly requests printing in a group conversation, but also when it is a specific day of the week.

[0096] In the flow shown in Figure 13, s1301 begins when bot service 321 determines that the conversation setting is a group conversation setting.

[0097] The processes from s1301 to s1303 are the same as the processes from s601 to s603 in Figure 6(a), so their explanation is omitted.

[0098] In S1301, if it is determined that the message is not an explicit instruction, the bot service 321 obtains the day of the week on which the message was received from the server's control unit 103 and determines whether it matches a specific day of the week that has been specified in advance (S1304). In S1304, if the day of the week does not match, the bot service 321 makes no suggestion (Figure 17(a)). In S1304, if the day of the week on which the message was received matches a specific day of the week, it suggests printing to the user (S1303) (Figures 17(b), 1701). The detailed process of suggesting printing to the user at this time is the same as in Figure 7(b), so the explanation is omitted.

[0099] In this example, we used days of the week, but the same method can be used for times and dates.

[0100] As described above, according to this embodiment, even when the bot service 321 is suppressing suggestions from the bot in a group conversation, it can improve convenience according to the user's needs by making suggestions from the printing bot at specific times / days / dates.

[0101] Furthermore, the present invention can also be realized by supplying a program that implements one or more of the functions of the above-described embodiments to a system or device via a network or storage medium, and by having one or more processors in the computer of that system or device read and execute the program. It can also be realized by a circuit (e.g., an ASIC) that implements one or more functions. [Explanation of symbols]

[0102] 101 Message application server 102 Printbot Server 103 Print Server 104 Client terminals 105 Printer 311 Messaging Service 321 Bot Service 331 Print Service

Claims

1. A detection process to detect when a file has been uploaded, A determination step to determine whether to print the uploaded file or to display a prompt for confirmation, If it is determined in the determination step to display a query, the display means will display the query. A program to cause the server system to execute a control step, which, if it is determined in the determination step that the display to be queried should not be displayed, controls the display means to prevent it from displaying the said query.

2. The aforementioned file is a file uploaded to the system on which the chat service operates. The program according to claim 1, characterized in that the display of the inquiry is achieved by writing an inquiry to the page provided by the chat service.

3. In the aforementioned determination step, The program according to claim 1 or 2, characterized in that it makes the determination based on whether or not multiple users are participating in the chat service room where the upload was made.

4. In the aforementioned determination step, The program according to any one of claims 1 to 3, characterized in that the determination is made based on the file name of the uploaded file.

5. A detection means for detecting when a file has been uploaded, A determination means for determining whether to print the uploaded file or to display a prompt for confirmation, If the determination means determines that a query should be displayed, the display means will be instructed to display the query. A server system characterized by having a control means that, if the determination means determines that the display to be queried should not be displayed, controls the display means to prevent the display to be queried from displaying the said query.

6. The aforementioned file is a file uploaded to the system on which the chat service operates. The server system according to claim 5, characterized in that the display of the inquiry is achieved by writing the inquiry to the page provided by the chat service.

7. The determination means is, The server system according to claim 5 or 6, characterized in that the determination is made based on whether or not multiple users are participating in the chat service room where the upload was made.

8. The determination means is, The server system according to any one of claims 5 to 7, characterized in that the determination is made based on the file name of the uploaded file.

Images