JP2020053767A - Communication device and computer program for the same - Google Patents

Abstract

To provide a technology capable of appropriately executing communication with an external device in a case where error notification is received from the external device although negotiation is normally executed.SOLUTION: A communication device comprises: a first request transmission unit that transmits a first negotiation request including first version information to a first external device; a first communication execution unit that executes first communication with the first external device while utilizing a predetermined communication protocol of a second version; a second request transmission unit that, in a case where error notification is received from the first external device in the first communication, transmits to the first external device a second negotiation request including second version information different from the first version information; and a second communication execution unit that executes second communication with the first external device while utilizing a predetermined communication protocol of a first version.SELECTED DRAWING: Figure 7

Description

  This specification discloses a communication device that executes negotiation regarding a predetermined communication protocol version with an external device.

  Patent Document 1 discloses a computing system environment including a client and a server. The client sends a negotiation request including the version number of the SMB protocol supported by the client to the server, and receives a negotiation response including the version number of the SMB protocol to be used from the server. The client communicates with the server according to the version number of the SMB protocol included in the negotiation response.

JP 2006-333433

  Even though the negotiation (ie, negotiation) for determining the version of the SMB protocol between the client and the server has been completed successfully, it is possible that the subsequent communication between the client and the server will not be performed properly. .

  The present specification provides a technology capable of appropriately executing communication with an external device when an error notification is received from the external device even though the negotiation has been normally performed.

  A communication device disclosed by the present specification includes a communication interface and a first request transmission unit that transmits a first negotiation request including first version information to a first external device via the communication interface. The first version information indicates that the communication device can use a plurality of versions of a predetermined communication protocol, and the plurality of versions include a first version and the first version. A first request transmission unit including a second version newer than a version, and the first external device in response to the first negotiation request being transmitted to the first external device. A response indicating that said first external device is able to use said second version of said predetermined communication protocol via said communication interface. A first communication execution unit that executes a first communication with the first external device using the second version of the predetermined communication protocol via the communication interface, In the first communication, when an error notification is received from the first external device, a second negotiation including second version information different from the first version information via the communication interface A second request transmission unit that transmits a request to the first external device, wherein the second version information is such that the communication device can use the first version of the predetermined communication protocol. The second request transmitting unit, and in response to the second negotiation request being transmitted to the first external device, the first external device sends the first When a response indicating that the external device can use the first version of the predetermined communication protocol is received, the external device uses the first version of the predetermined communication protocol via the communication interface. And a second communication execution unit that executes a second communication with the first external device.

  According to the above configuration, in the first communication with the first external device using the second version of the predetermined communication protocol, when the communication device receives an error notification from the first external device, A second negotiation request including version information of the second negotiation is transmitted to the first external device. When the communication device receives a response from the first external device indicating that the first external device can use the first version of the predetermined communication protocol, the communication device receives the first version of the predetermined communication protocol. To perform a second communication with the first external device using the communication. In this case, since the second communication using the predetermined communication protocol of the first version that is older than the second version is performed, the possibility of not receiving an error notification from the first external device may increase. Therefore, the communication device can appropriately execute communication with the first external device when an error notification is received from the first external device even though the negotiation has been normally performed.

  A control method for realizing the above communication device, a computer program, and a computer-readable recording medium storing the computer program are also novel and useful. Further, a communication system including the above communication device and the first external device is also new and useful.

1 shows a configuration of a communication system. An example of each table is shown. FIG. 8 shows a sequence diagram of case A in which communication using SMB 1.0 is successful. FIG. 11 shows a sequence diagram of a case B in which communication using SMB 2.0 is successful. FIG. 11 shows a sequence diagram of a case C in which communication using SMB2.1 is successful. FIG. 8 shows a sequence diagram of case D in which communication using SMB2.1 fails. FIG. 9 shows a sequence diagram of a case E in which communication using SMB 2.0 fails. FIG. 9 shows a sequence diagram of case F in which scan data communication using SMB 1.0 is executed. FIG. 9 shows a sequence diagram of case G in which communication of scan data is restricted. 4 shows a flowchart of a connection process. 4 shows a flowchart of a test connection process. 4 shows an example of a screen displayed on a PC. 4 shows an example of a screen displayed on a PC. 4 shows an example of a screen displayed on the MFP.

(Example)
(Configuration of communication system 2; FIG. 1)
As shown in FIG. 1, the communication system 2 includes a multi-function device 10 (hereinafter, referred to as “MFP (abbreviation for Multi-Function Peripheral)”), a PC 60, and a plurality of servers 100A to 100E. The MFP 10, the PC 60, and the servers 100A to 100E belong to the same LAN (abbreviated as Local Area Network) 4, and can communicate with each other via the LAN 4.

(Configuration of MFP 10)
The MFP 10 is a peripheral device that can execute multiple functions including a printing function, a scanning function, and a web server function. The web server function is a function of transmitting web page data representing a web page to an external device when the external device accesses a web server of MFP 10. The MFP 10 can use SMB (abbreviation of Service Message Block) which is a file sharing protocol. In particular, the MFP 10 can use SMB 1.0, SMB 2.0, SMB 2.1, and SMB 3.0. The value after the SMB indicates the version of the SMB protocol. A larger version value indicates a newer version. It should be noted that the term “dialect” may be used as a term expressed in the version of the SMB protocol.

  The MFP 10 includes an operation unit 12, a display unit 14, a print execution unit 16, a scan execution unit 18, a communication interface (hereinafter, the interface is referred to as “I / F”) 20, and a control unit 30. Prepare.

  The operation unit 12 includes a plurality of keys. The user can input various instructions to the MFP 10 by operating the operation unit 12. The display unit 14 is a display for displaying various information. The display unit 14 also functions as a so-called touch panel (that is, an operation unit). The printing unit 16 is a printing mechanism of an ink jet system, a laser system, or the like. The scan execution unit 18 is a scan mechanism such as a CCD and a CIS.

  The control unit 30 includes a CPU 32 and a memory 34. The CPU 32 executes various processes according to the program 36 stored in the memory 34. The memory 34 includes a volatile memory, a nonvolatile memory, and the like. The memory 34 stores a profile table 38 (see FIG. 2) and an IP address 40. IP address 40 is an IP address assigned to MFP 10.

(Configuration of servers 100A to 100E)
The server 100A is a server that stores a shared folder for file sharing. The server name “server1” is assigned to the server 100A. The server 100A can use the SMB protocol, in particular, can use only the SMB 1.0 (ie, cannot use a version newer than the SMB 1.0). The server 100A stores an authentication table 110A (see FIG. 2).

  The servers 100B to 100E have the same configuration as the server 100A except that the available SMB protocol version is different. Server names “server2”, “server3”, “server4”, and “server5” are assigned to the servers 100B, 100C, 100D, and 100E, respectively. The servers 100B, 100E can use SMB1.0 and SMB2.0 (that is, the versions newer than SMB2.0 cannot be used), and the servers 100C, 100D can use SMB1.0, SMB2.0, and SMB2.0. , SMB2.1 is available (ie, a version newer than SMB2.1 is not available). When the SMB protocol version is newer than 2.0, the interpretation of the SMB protocol has a wide range. For this reason, even if the programs are compatible with the same version of the SMB protocol, the contents of the programs may be different for each vendor. In this embodiment, the servers 100A to 100C are servers provided by the same vendor. The servers 100C, 100D, and 100E are servers provided by different servers. The program corresponding to SMB2.1 mounted on server 100C is consistent with the program corresponding to SMB2.1 mounted on MFP 10. On the other hand, the program corresponding to SMB2.1 mounted on the server 100D does not match the program corresponding to SMB2.1 mounted on the MFP 10. The programs corresponding to SMB 2.0 mounted on servers 100B and 100D are consistent with the programs corresponding to SMB 2.0 mounted on MFP 10. On the other hand, the program corresponding to the SMB protocol 2.0 mounted on the server 100E has a problem or is not consistent with the program corresponding to the SMB 2.0 mounted on the MFP 10.

(Contents of tables 38 and 110A; FIG. 2)
Next, the contents of the profile table 38 in the MFP 10 and the authentication table 110A in the server 100A will be described with reference to FIG.

  In the profile table 38 of the MFP 10, profile names (profiles 1 to 5) and profile information are stored in association with each other. The profile information includes a network folder path, a user name, a password, and an SMB version. The profile name is a name for identifying profile information, and is registered in advance when the MFP 10 is shipped. In the modification, when a user registers a user name and a password in the profile table 38, a new profile name may be created. The network folder path is a path of a shared folder in the server. The user name and the password are information for identifying the user. The SMB version is information indicating the version of the SMB protocol to be used for communication with the server. The profile table 38 is used when executing the scan_to_Network function. This function is a function of storing scan data in a shared folder in the server.

  The authentication table 110A of the server 100A is a table indicating whether access to the shared folder in the server 100A is permitted. In the authentication table 110A, a user name, a password, access information to the shared folder “shared11”, and access information to the shared folder “shared12” are stored in association with each other. The access information has a value of either “OK” indicating that access to the shared folder is permitted or “NG” indicating that access to the shared folder is prohibited. Information in the authentication table 110A is set by the administrator of the server 100A. The servers 100B to 100E also store the same authentication table as the authentication table 110A.

(Specific case; FIGS. 3 to 9)
With reference to FIGS. 3 to 9, specific cases A to F realized by the communication system 2 of the present embodiment will be described.

(Case A; FIG. 3)
A case A in which profile information is registered in association with profile 1 in profile table 38 (see FIG. 2) will be described with reference to FIG. In case A, profile information for storing scan data in the shared folder “shared11” of the server 100A is registered. In the initial state of Case A, no profile information is registered in the profile table 38 (see FIG. 2) of the MFP 10. The user name “UUU1” and the password “PPP1” have already been registered in the authentication table 110A (see FIG. 2) of the server 100A, and the user name “UUU1” has access information to the shared folder “shared11”. “OK” is set. All the following communications executed by the MFP 10 are executed via the communication I / F 20. Therefore, the description “via the communication I / F 20” will be omitted below.

  When receiving the input of the IP address 40 of the MFP 10 while the Web browser is running in T10, the PC 60 transmits a top screen data request to the MFP 10 in T12, and receives the top screen data from the MFP 10 in T14. , T16, the top screen D1 represented by the top screen data is displayed. As shown in FIG. 12A, the screen D1 includes a basic information column and a scan tab. In the basic information column, the current status of the MFP 10 and the remaining ink amount are described.

  When the scan tab in the top screen D1 is operated at T20, the PC 60 transmits a selection screen data request to the MFP 10 at T22, receives the selection screen data from the MFP 10 at T24, and selects the selection screen data at T26. Is displayed. As shown in FIG. 12B, five profile names (that is, profiles 1 to 5) are described on the screen D2.

  When receiving the operation for selecting the profile 1 in T30, the PC 60 transmits a setting screen data request to the MFP 10 in T32, receives the setting screen data from the MFP 10 in T34, and receives the setting screen data in T36 according to the setting screen data. The displayed setting screen D3 is displayed. As shown in FIG. 12C, the screen D3 includes a profile 1, a network folder path input field, a user name input field, a password input field, a test connection button, and a cancel button.

  In T40, the network folder path “\\ server1 \ shared11”, the user name “UUU1”, and the password “PPP1” are input to the screen D3 at T40, and the test connection button in the screen D3 is operated at T42. At T50, a test connection request including “Profile 1”, “\\ server1 \ shared11”, “UUU1”, and “PPP1” is transmitted to the MFP 10.

  Upon receiving the test connection request from the PC 60 at T50, the MFP 10 transmits the connection screen data to the PC 60 at T52.

  Upon receiving the connection screen data from the MFP 10 at T52, the PC 60 displays a connection screen D4 represented by the connection screen data at T54. As shown in FIG. 12D, screen D4 includes profile 1, a message indicating that test connection is being executed, and a cancel button. Here, the “test connection” is a process for confirming whether or not the shared folder in the server can be accessed.

  At T60, MFP 10 transmits a Negotiate request including the version information to server 100A. The Negotiate request is a negotiation request for determining the version of the SMB protocol used for communication between the MFP 10 and the server 100A. The version information is information indicating the version of the SMB protocol that can be used by the MFP 10, and the version information transmitted in T60 includes “SMB2.?”, “SMB2.0”, and “SMB1.0”. “SMB2.?” Is information indicating that a version higher than “SMB2.1” can be used.

  Upon receiving the Negotiate request from the MFP 10 at T60, the server 100A determines the version of the SMB protocol used for communication with the MFP 10 using the version information in the request. The server 100A determines that “SMB1.0” is to be used because only “SMB1.0” is available and “SMB1.0” is included in the version information. Then, in T62, server 100A transmits a Negotiate response including “SMB1.0” to MFP 10.

  At T62, the MFP 10 receives a Negotiate response from the server 100A. Since the Negotiate response includes “SMB1.0”, the MFP 10 determines “SMB1.0” as the version of the SMB protocol used in the subsequent communication with the server 100A. Next, at T70, the MFP 10 transmits a Session Setup request including the user name “UUU1” and the password “PPP1” in the test connection request to the server 100A. The Session Setup request is a request for establishing a session with the server.

  Upon receiving the Session Setup request from the MFP 10 at T70, the server 100A determines that the user name “UUU1” and the password “PPP1” in the request match the user name and the password registered in the authentication table 110A, At T72, a Session Setup response including the status “SUCCESS” is transmitted to MFP 10.

  Upon receiving the Session Setup response from the server 100A at T72, the MFP 10 determines that the session with the server 100A has been successfully established because the response includes the status “SUCCESS”. Then, at T80, the MFP 10 transmits a Tree Connect request including the network folder path “\\ server1 \ shared11” in the test connection request to the server 100A. The Tree Connect request is a request for confirming whether access to the network folder path (that is, the shared folder) in the request is permitted.

  When the server 100A receives the Tree Connect request from the MFP 10 at T80, the access information of the network folder path “\\ server1 \ shared11” associated with the user name “PPP1” in the authentication table 110A is “OK”. That is, it is determined that access to the network folder path is permitted. Then, in T82, the server 100A transmits a Tree Connect response including the status “SUCCESS” to the MFP 10.

  Upon receiving the Tree Connect response from the server 100A at T82, the MFP 10 determines that the test connection was successful because the response includes the status “SUCCESS”. Then, in T84, the MFP 10 registers profile information including the network folder path “\\ server1 \ shared11”, the user name “UUU1”, and the password “PPP1” in association with the profile 1 in the profile table 38. . Note that the MFP 10 does not register information in the SMB version of the profile 1. Further, at T90, the MFP 10 transmits a success notification indicating that the test connection has been successful to the PC 60.

  Upon receiving the success notification at T90, the PC 60 displays a connection success screen D5 at T92. As shown in FIG. 12E, the screen D5 includes a message indicating that the test connection has been successful, and an OK button. Thereby, the user of the PC 60 can know that the test connection to the server 100A has succeeded and that the registration of the profile 1 has been completed. Thereby, the scan_to_Network function using the profile 1 can be used.

(Case B; FIG. 4)
Next, a case B in which profile information is registered in association with profile 2 of the profile table 38 (see FIG. 2) will be described with reference to FIG. In case B, profile information for storing the scan data in the shared folder “shared21” of the server 100B is registered. Case B is a state after case A, in which profile information is registered in profile 1 of profile table 38 (see T84 in FIG. 3). The user name “UUU1” and the password “PPP1” have already been registered in the authentication table in the server 100B, and “OK” is set in the user name “UUU1” as access information to the shared folder “shared21”. Have been.

  First, the same processing as T10 to T42 in FIG. 3 is executed between the PC 60 and the MFP 10. In this case, the user of the PC 60 operates the profile 2 on the profile selection screen D2 (see FIG. 12 (B)), and enters the network folder path “ \\ server2 \ shared21 ", user name" UUU1 ", and password" PPP1 ".

  At T150, PC 60 transmits a test connection request including “Profile 2”, “\\ server2 \ shared21”, “UUU1”, and “PPP1” to MFP 10. T152 and T154 are the same as T52 and T54 in FIG. 3, respectively. T160 is the same as T60 except that the communication target is the server 100B.

  Upon receiving the Negotiate request from MFP 10 at T160, server 100B determines that “SMB1.0” and “SMB2.0” available for server 100B are included in the version information of the request. Next, the server 100B determines to use the newest version “SMB2.0” of “SMB1.0” and “SMB2.0” available for the server 100B. Then, in T162, server 100B transmits a Negotiate response including “SMB2.0” to MFP 10. T170 and T172 are the same as T70 and T72 in FIG. 3, respectively, except that the communication target is the server 100B.

  At T180, the MFP 10 transmits a Tree Connect request including the network folder path “\\ server2 \ shared21” and the number of Credit Requests “2” to the server 100B. The number of Credit Requests is information indicating the number of Credits that a device (eg, the MFP 10) operating as a client requests a device (eg, the server 100B) operating as a server in communication using the SMB protocol. The device operating as a client receives the Credit Granted number from the device operating as a server in response to the transmission of the Credit Request. The device operating as a client can simultaneously transmit request signals to the device operating as a server by the number of received Credit Granted numbers. In this embodiment, the MFP 10 transmits a predetermined number of Credit Requests “2”.

  Upon receiving the Tree Connect request from the MFP 10 at T182, the server 100B sets the access information of the network folder path “\\ server2 \ shared21” associated with the user name “PPP1” in the authentication table of the server 100B to “OK”. Is determined, and it is determined that access to the network folder path is permitted. Further, the server 100B specifies “2” as the Credit Grated number. Then, in T182, the server 100B transmits a Tree Connect response including the status “SUCCESS” and the Credit Granted number “2” to the MFP 10.

  At T184, the MFP 10 registers profile information including the network folder path “\\ server2 \ shared21”, the user name “UUU1”, and the password “PPP1” in association with the profile 2 in the profile table 38. Note that the MFP 10 does not register information in the SMB version of the profile 2. T190 and T192 are the same as T90 and T92 in FIG. 3, respectively. Thus, the scan_to_Network function using the profile 2 can be used.

(Case C; FIG. 5)
Next, a case C in which profile information is registered in association with the profile 3 of the profile table 38 (see FIG. 2) will be described with reference to FIG. In case C, profile information for storing the scan data in the shared folder “shared31” of the server 100C is registered. Case C is a state after case B, in which profile information is registered in profiles 1 and 2 of the profile table 38 (see T184 in FIG. 4). The user name “UUU1” and the password “PPP1” are already registered in the authentication table in the server 100C, and “OK” is set in the user name “UUU1” as access information to the shared folder “shared31”. Have been.

  First, the same processing as T10 to T42 in FIG. 3 is executed between the PC 60 and the MFP 10. In this case, the user of the PC 60 operates the profile 3 on the profile selection screen D2 (see FIG. 12 (B)), and enters the network folder path “ \\ server3 \ shared31 ", user name" UUU1 ", and password" PPP1 ".

  At T250, PC 60 transmits a test connection request including “Profile 3”, “\\ server3 \ shared31”, “UUU1”, and “PPP1” to MFP 10. T252 and T254 are the same as T52 and T54 in FIG. 3, respectively. T260 is the same as T60 except that the communication target is the server 100C.

  Upon receiving the Negotiate request from MFP 10 at T260, server 100C includes “SMB1.0”, “SMB2.0”, and “SMB2.1” available for server 100C in the version information of the request. Judge that Next, the server 100C determines to use the newest version “SMB2.1” among “SMB1.0”, “SMB2.0”, and “SMB2.1” available to the server 100C. . Then, in T262, server 100C transmits a Negotiate response including “SMB2.?” Corresponding to “SMB2.1” to MFP 10.

  Upon receiving the Negotiate response from the server 100C in T262, the MFP 10 determines that communication using a version of SMB 2.1 or higher is desired because the response includes “SMB2.?”. In this case, the MFP 10 is a version (“SMB2.1” or higher) of “SMB1.0”, “SMB2.0”, “SMB2.1”, and “SMB3.0” that can be used by the MFP 10. That is, “SMB2.1” and “SMB3.0” are specified. Next, in T264, the MFP 10 generates a GUID (abbreviation for Globally Unique Identifier) “XXX1”. The GUID is a random character string for identifying the MFP 10 and is information generated when communication using “SMB2.1” or a newer version is performed for the first time after the MFP 10 is turned on. is there. In the modification, the GUID may be generated when the power of the MFP 10 is turned on. Then, at T266, the MFP 10 transmits to the server 100C a Negotiate request including the version information including the specified “SMB2.1” and “SMB3.0” and the generated GUID “XXX1”.

  Upon receiving the Negotiate request from MFP 10 at T266, server 100C stores the GUID “XXX1” in the request at T268. Then, the server 100C determines that “SMB2.1” available for the server 100C is included in the version information of the request, and determines to use “SMB2.1”. Next, in T270, server 100C transmits a Negotiate response including “SMB2.1” to MFP 10. T280 to T292 are the same as T170 to T182 in FIG. 4 except that the communication target is the server 100C.

  Upon receiving the Tree Connect response including the status “SUCCESS” from the server 100C in T292, the MFP 10 transmits a Validate Negotiate Info request including the GUID “XXX1” generated in T264 to the server 100C in T300. The Validate Negotiate Info request is a signal communicated in “SMB2.1” and newer versions, and is used to verify whether the source of the Negotiate request and the source of the Validate Negotiate Info request are the same. Signal.

  Upon receiving the Validate Negotiate Info request from the MFP 10 at T300, the server 100C determines that the GUID “XXX1” in the request matches the GUID “XXX1” stored at T268, and determines the source of the Negotiate request and the Validate Negotiate It is determined that the source of the Info request is the same. Then, in T302, the server 100C transmits a Validate Negotiate Info response including the status “SUCCESS” to the MFP 10.

  Upon receiving the Validate Negotiate Info response from the server 100C at T302, the MFP 10 determines that the verification by the server 100C was successful because the request includes the status “SUCCESS”. Then, in T304, the MFP 10 registers profile information including the network folder path “\\ server3 \ shared31”, the user name “UUU1”, and the password “PPP1” in association with the profile 3 in the profile table 38. . Note that the MFP 10 does not register information in the SMB version of the profile 3. T310 and T312 are the same as T90 and T92 in FIG. 3, respectively.

(Case D; FIG. 6)
Next, a case D in which profile information is registered in association with the profile 4 of the profile table 38 (see FIG. 2) will be described with reference to FIG. In case D, profile information for storing scan data in the shared folder “shared41” of the server 100D is registered. Case D is a state after case C, and profile information is registered in profiles 1 to 3 of the profile table 38 (see T304 in FIG. 5). The user name “UUU1” and the password “PPP1” are already registered in the authentication table in the server 100D, and “OK” is set in the user name “UUU1” as access information to the shared folder “shared41”. Have been. In addition, the MFP 10 has generated the GUID “XXX1” (see T264 in FIG. 5).

  First, the same processing as T10 to T42 in FIG. 3 is executed between the PC 60 and the MFP 10. In this case, the user of the PC 60 operates the profile 4 on the profile selection screen D2 (see FIG. 12B), and enters the network folder path “ \\ server4 \ shared41 ", user name" UUU1 ", and password" PPP1 ".

  At T450, PC 60 transmits a test connection request including “profile 4”, “\\ server4 \ shared41”, “UUU1”, and “PPP1” to MFP 10. T452 and T454 are the same as T252 and T254 in FIG. 5, respectively. T460, T462, and T466 are the same as T260, T262, and T266, respectively, except that the communication target is the server 100D.

  Since the server 100D is provided by a vendor different from the MFP 10, the server 100D does not include a program for using a GUID even though “SMB2.1” is available. For this reason, even if the server 100D receives the Negotiate request including the GUID “XXX1” from the MFP 10 in T466, the server 100D transmits the Negotiate request including “SMB2.1” to the MFP 10 in T470 without storing the GUID. I do.

  T480 to T500 are the same as T280 to T300 in FIG. 5 except that the communication target is the server 100D. As described above, the server 100D does not include a program for using a GUID. Therefore, even if the server 100D receives the Validate Negotiate Info request from the MFP 10 at T500, the server 100D cannot interpret the request. In this case, server T transmits a TCP RST signal to MFP at T502. The TCP RST signal is a signal for requesting disconnection of the session with the MFP 10, and is a signal indicating that the server 100D cannot interpret the Validate Negotiate Info request. The Negotiate request, Negotiate response, Session Setup request, Session Setup reception, Tree Connect request, Tree Connect response, Validate Negotiate Info request, and Validate Negotiate Info response are communicated using the application layer of the OSI reference model. The TCP RST signal is a signal that is communicated using a transport layer that is lower than the application layer.

  Upon receiving the TCP RST signal from server 100D in T502, MFP 10 determines that the test connection with server 100D using “SMB2.1” has failed, and in T510, a failure notification including the first connection failure screen data. To the PC 60.

  Upon receiving the failure notification from the MFP 10 at T510, the PC 60 displays a first connection failure screen D7 represented by the first connection failure screen data in the notification at T512. As shown in FIG. 13A, a screen D7 displays a message indicating that the test connection using “SMB2.1” has failed and “SMB2.0” which is a version older than “SMB2.1”. , A message for inquiring whether or not to attempt a test connection in the above, two check boxes corresponding to “Yes” and “No”, and an OK button. Therefore, the user can select whether or not to cause the MFP 10 to execute a test connection using an older version of the SMB protocol. In T514, the PC 60 accepts the addition of the check to the check box corresponding to “Yes” and accepts the operation of the OK button. In T516, the PC 60 “Profile 4”, “\\ server4 \ shared41”, “UUU1”, Then, a retest connection request including “PPP1” is transmitted to MFP 10. T518 and T520 are the same as T452 and T454, respectively.

  In T516, when the MFP 10 receives the retest connection request from the PC 60 at T516, the MFP 10 is requested to perform the second test connection using a version of "SMB2.0" older than "SMB2.1" in which the first test connection failed. In T530, a Negotiate request including “SMB2.0” and “SMB1.0” is transmitted to the server 100D. In other words, the Negotiate request transmitted in T530 includes “SMB2.?” Corresponding to “SMB2.1” for which the first test connection failed even though MFP 10 can use “SMB2.1.” Not included. Therefore, it is possible to prevent the communication using “SMB2.1” from being executed in the second test connection, and to reduce the possibility that the test connection repeatedly fails.

  Upon receiving the Negotiate request from MFP 10 in T530, server 100D determines to use “SMB2.0”, and transmits a Negotiate response including “SMB2.0” to MFP 10 in T532. T540 to T562 are the same as T170 to T192 in FIG. 4 except that the communication target is the server 100D. At T554, the MFP 10 associates the network folder path “\\ server4 \ shared41”, the user name “UUU1”, the password “PPP1”, and “SMB2.0” with the profile 4 in the profile table 38. Register the profile information including. That is, “SMB2.0” is registered as the SMB version in the profile table 38.

(Case E; FIG. 7)
Next, a case D in which profile information is registered in association with the profile 5 of the profile table 38 will be described with reference to FIG. In case E, profile information for storing the scan data in the shared folder “shared51” of the server 100E is registered. Case E is a state after case D, in which profile information is registered in profiles 1 to 4 of the profile table 38 (see T554 in FIG. 6). Also, the user name “UUU1” and the password “PPP1” have been registered in the authentication table in the server 100E, and “OK” is set in the user name “UUU1” as access information to the shared folder “shared51”. Have been.

  First, the same processing as T10 to T42 in FIG. 3 is executed between the PC 60 and the MFP 10. In this case, the user of the PC 60 operates the profile 5 on the profile selection screen D2 (see FIG. 12 (B)), and enters the network folder path “ \\ server5 \ shared51 ", user name" UUU1 ", and password" PPP1 ".

  At T650, PC 60 transmits a test connection request including “Profile 5”, “\\ server5 \ shared51”, “UUU1”, and “PPP1” to MFP 10. T652 to T680 are the same as T152 to T180 in FIG. 4 except that the communication target is the server 100E.

  Upon receiving the Tree Connect request from MFP 10 in T680, server 100E transmits a Tree Connect response including status "USER_SESSION_DELETED" in T682, despite the successful establishment of the session with MFP 10 in T670 and T672. Send to MFP 10. The status is information indicating that the session between the MFP 10 and the server 100E has been disconnected. The reason why such a Tree Connect response is transmitted from the server 100E is, for example, that a program installed in the server 100E has a problem, a program installed in the MFP 10 and a program installed in the server 100E. And that the number of Credit Requests in the Tree Connect request is larger than the upper limit of the number of Credits that the server 100E can tolerate.

  Upon receiving the Tree Connect response from the server 100E in T682, the MFP 10 determines that the test connection with the server 100E using “SMB2.0” has failed because the response includes the status “USER_SESSION_DELETED”. , A failure notification including the second connection failure screen data is transmitted to the PC 60.

  Upon receiving the failure notification from the MFP 10 at T690, the PC 60 displays a second connection failure screen D8 represented by the second connection failure screen data in the notification at T692. As shown in FIG. 13B, the screen D8 includes a message indicating that the test connection using “SMB2.0” has failed and “SMB1.0” which is a version older than “SMB2.0”. A message inquiring whether or not to attempt a test connection in the above, a message indicating that security strength is likely to be reduced, two check boxes corresponding to “Yes” and “No”, an OK button, including. Unlike the first connection failure screen D7 shown in FIG. 13A, the second connection failure screen D8 includes a message indicating that security strength is likely to be reduced. For this reason, the user can know that the security strength is reduced by using “SMB1.0”. In the modification, the first connection failure screen D7 may also include a message indicating that security strength is likely to be reduced. In T694, the PC 60 accepts the addition of the check to the check box corresponding to “Yes” and accepts the operation of the OK button. In T696, the PC 60 determines “Profile 5”, “\\ server5 \ shared51”, “UUU1”, Then, a retest connection request including “PPP1” and “SMB1.0” is transmitted to the MFP 10. T698 and T700 are the same as T652 and T654, respectively.

  Upon receiving the retest connection request from the PC 60 in T696, the MFP 10 executes a second test connection using a version of “SMB1.0” that is older than “SMB2.0” in which the first test connection failed. It is determined that the request has been made, and in T710, a Negotiate request including “SMB1.0” is transmitted to the server 100E. That is, in the Negotiate request transmitted in T710, the first test connection failed even though the MFP 10 can use “SMB2.0”, “SMB2.1”, and “SMB3.0”. “SMB2.0” and newer “SMB2.?” Are not included. Therefore, it is possible to prevent communication using “SMB 2.0” from being executed in the second test connection, and to reduce the possibility that the test connection will fail.

  Upon receiving the Negotiate request from MFP 10 in T710, server 100E determines to use “SMB1.0”, and transmits a Negotiate response including “SMB1.0” to MFP 10 in T712. T720 to T742 are the same as T70 to T92 in FIG. 3 except that the communication target is the server 100E. In T734, the MFP 10 associates the network folder path “\\ server5 \ shared51”, the user name “UUU1”, the password “PPP1”, and “SMB1.0” in association with the profile 5 in the profile table 38. Register the profile information including.

(Case F; FIG. 8)
Next, a case F in which the MFP 10 executes the scan_to_Network function will be described with reference to FIG. Case F is a state after case E, in which profile information is registered in profiles 1 to 5 of the profile table 38 (see FIG. 2) of the MFP 10 (see T734 in FIG. 7).

  When the screen display operation is received by the operation unit 12 at T800, the MFP 10 displays a function selection screen D11 at T802. As shown in FIG. 14A, the screen D11 includes a Copy button, a Scan button, and a setting button. The Copy button is a button for selecting use of a copy function, the Scan button is a button for selecting use of a scan function, and the setting button is a button for executing network settings and the like of the MFP 10. is there.

  Upon receiving an operation on the Scan button in T804, the MFP 10 displays a transmission destination selection screen D12 in T806. As shown in FIG. 14B, screen D12 includes a “To e-mail” button, a “To Network” button, and a “To USB” button. The “To e-mail” button is a button for selecting transmission of an e-mail with scan data attached. The “To Network” button is also a button for selecting transmission of scan data to a server on the network, that is, a button for selecting execution of the scan_to_Network function. The “To USB” button is a button for transmitting scan data to USB.

  Upon receiving the operation on the “To Network” button in T808, the MFP 10 displays the profile selection screen D13 in T810. As shown in FIG. 14C, screen D13 includes profiles 1 to 5 for which profile information has been registered. When the MFP 10 receives the operation on the profile 5 in T812, the MFP 10 acquires a proximity scan instruction including the profile 5 in T814, starts scanning the document set in the MFP 10 in T816, and scans the scan screen in T818. D14 is displayed. As shown in FIG. 14D, screen D14 includes a message indicating that scanning of a document is being executed. When the generation of the scan data is completed in T820, the MFP 10 displays a data transmission screen D15 in T822. As shown in FIG. 14E, screen D15 includes a message indicating that the scan data is being transmitted.

  In the profile table 38, the MFP 10 specifies that “SMB1.0” is stored in the SMB version of the profile 5 and that the network folder path of the profile 5 includes the server name “server5” of the server 100E. Then, in T830, the MFP 10 transmits a Negotiate request not including the SMB “2.?” And “SMB2.0” and including only the specified SMB “1.0” to the specified server 100E. Subsequent T832 to T852 are the same as T712 to T732 in FIG. Thereby, the scan data can be transmitted to the server 100E.

  At T860, scan data transmission processing is performed between MFP 10 and server 100E, and the scan data is transmitted from MFP 10 to server 100E. From the viewpoint of the MFP 10, the scan data transmission process includes transmission of a Create File request, reception of a response to the request, transmission of a Write File request, and reception of the response. Thereby, the server 100E receives the scan data, and in T862, stores the scan data in the shared folder “shared51”.

  When the scan data transmission process with the server 100E is completed, the MFP 10 displays a completion screen D16. As shown in FIG. 14 (F), screen D16 includes a message indicating that transmission of scan data to server 100E has been completed. This allows the user to know that the scan data has been saved in the shared folder “shared51” in the server 100E. Thereafter, the user can use the scan data by accessing the folder “shared51” using the PC 60, for example.

  If “SMB1.0” is not stored in T734 of FIG. 7, in T830, the MFP 10 sends a Negotiate request including “SMB2.?”, “SMB2.0”, and “SMB1.0” as version information. Send it to server 100E. In this case, communication (T670 to T682) using “SMB2.0” is performed between the MFP 10 and the server 100E. That is, the MFP 10 cannot access the shared folder “shared51” to receive the Tree Connect response including the status “USER_SESSION_DELETED” from the server 100E, and does not transmit the scan data to the server 100E. On the other hand, in the present embodiment, “SMB1.0” is stored in T734 of FIG. In this case, in T830, the MFP 10 transmits a Negotiate request including only “SMB1.0” to the server 100E. Therefore, communication (T840 to T852) using “SMB1.0” is executed between the MFP 10 and the server 100E. Therefore, the MFP 10 can access the shared folder “shared51” of the server 100E, and transmits the scan data to the server 100E. As a result, the scan data is stored in the shared folder “shared51” of the server 100E. Therefore, the MFP 10 can appropriately execute communication with the server 100E by storing the version of the SMB protocol in the profile table 38.

  Further, if the profile 4 is operated in T812, the MFP 10 acquires the proximity scan instruction including the profile 4, and “SMB 2.0” is stored in the profile table 38 as the SMB version of the profile 4. And transmits a Negotiate request including only the specified “SMB2.0” to the server 100D. Thereafter, the same processing as T532 to T552 and T860 in FIG. 6 is executed between the MFP 10 and the server 100D, and the scan data is stored in the shared folder “shared41” in the server 100D. Therefore, the MFP 10 can appropriately store the scan data in the shared folder using the SMB protocol of a version suitable for each of the servers 100D and 100E.

(Case G; FIG. 9)
Next, a case G in which execution of the scan_to_Network function is requested by accessing the web server of the MFP 10 will be described with reference to FIG. The initial state in FIG. 9 is the same as the initial state in FIG.

  T900 to T926 are the same as T10 to T26 in FIG. Upon receiving the operation for profile 5 in T930, the PC 60 transmits a scan selection screen data request to the MFP 10 in T932, receives the scan selection screen data from the MFP 10 in T934, and displays the scan selection screen D6 in T936. indicate. As shown in FIG. 12E, screen D6 is similar to setting screen D3 except that a Scan button is displayed instead of a test connection button. Upon accepting the operation on the Scan button in T940, the PC 60 transmits a remote scan instruction including the profile 5 to the MFP 10 in T942.

  Upon receiving the remote scan instruction from the PC 60 in T942, the MFP 10 stores “SMB1.0” in the SMB version of the profile 5 in the instruction in the profile table 38, and checks the network folder path of the profile 5 Contains the server name “server5” of the server 100E. In this case, the MFP 10 stops executing the scan_to_Network function because the SMB version is “SMB1.0”. Then, in T944, the MFP 10 transmits the error screen data to the PC 60.

  Upon receiving the error screen data from the MFP 10 at T944, the PC 60 displays an error screen at T946. Thus, the user can know that the scan_to_Network function using the PC 60 is restricted.

  As shown in Cases F and G, the MFP 10 executes the scan_to_Network function when the proximity scan instruction is acquired in a state where “SMB1.0” is stored in the SMB version in the profile table 38. When the remote scan instruction is obtained, the scan_to_Network function is not executed. Therefore, when a remote scan instruction is acquired, it is possible to suppress execution of communication using “SMB1.0” with low security strength.

(Connection process; FIG. 10)
Subsequently, a connection process executed by the CPU 32 of the MFP 10 will be described with reference to FIG. When the power of the MFP 10 is turned on by the user, the processing in FIG. 10 is started.

  In S10, the CPU 32 monitors reception of a test connection request from the PC. When the test connection request is received from the PC (YES in S10), the CPU 32 proceeds to S12. The test connection request includes a profile name, a network folder path, a user name, and a password.

  In S12, the CPU 32 executes a test connection process (FIG. 11). The test connection process is a process of executing a test connection for confirming whether or not the shared folder in the server can be accessed. When S12 ends, the processing in FIG. 10 ends.

  Further, the CPU 32 executes the monitoring of S20 in parallel with the monitoring of S10. In S20, the CPU 32 monitors acquisition of a scan instruction including a profile name. Hereinafter, the profile name in the scan instruction is referred to as “scan profile name”.

  In S22, the CPU 32 determines whether or not the scan instruction is a remote scan instruction. When the scan instruction is the remote scan instruction (YES in S22, case G in FIG. 9), the CPU 32 proceeds to S24. On the other hand, when the scan instruction is the proximity scan instruction (NO in S22, case F in FIG. 8), the CPU 32 proceeds to S30.

  In S24, the CPU 32 determines whether or not the SMB version of the scan profile name is “SMB1.0” in the profile table 38. When the SMB version is “SMB1.0” (YES in S24), the CPU 32 proceeds to S26, and executes an error process in S26. In the error processing, the CPU 32 transmits the error screen data to the device that has transmitted the remote scan instruction without executing the scan_to_Network function. When S26 ends, the processing in FIG. 10 ends.

  On the other hand, when the SMB version of the scan profile name is “SMB2.0” or more or is empty (NO in S24), the CPU 32 proceeds to S30. In S30, the CPU 32 executes a scan process for scanning a document set on the MFP 10.

  In S32, the CPU 32 executes a server connection process for accessing a shared folder having a network folder path corresponding to the scan profile name in the profile table 38. The server connection process includes a Negotiate process, a Session Setup process, and a Tree Connect process. The server connection process includes a Validate process when it is determined in the Negotiate process that a version of “SMB2.1” or higher is used.

  In S34, the CPU 32 transmits the scan data to the server. As a result, the scan data is stored in the shared folder in the server. When S34 ends, the processing in FIG. 10 ends.

(Test connection process; FIG. 11)
Subsequently, the test connection process executed in S12 of FIG. 10 will be described with reference to FIG. In the following, the PC that is the source of the test connection request and the server that performs communication with MFP 10 are referred to as “target PC” and “target server”, respectively.

  The CPU 32 executes a Negotiate process with the target server in S50, and determines in S52 whether the Negotiate process has succeeded. When the Negotiate response is received from the target server in response to transmitting the Negotiate request to the target server, the CPU 32 determines that the Negotiate process has been successful (YES in S52), and proceeds to S60. On the other hand, when receiving the TCP RST signal from the target server, the CPU 32 determines that the Negotiate process has failed (NO in S52), and ends the process in FIG.

  The CPU 32 executes the Session Setup process with the target server in S60, and determines whether or not the Session Setup process was successful in S62. The CPU 32 determines that the Session Setup process was successful when a Session Setup response including the status “SUCCESS” is received from the target server in response to transmitting the Session Setup request to the target server in the Session Setup process. Then (YES in S62), the process proceeds to S70. On the other hand, when a Session Setup response or a TCP RST signal including a status other than the status “SUCCESS” (for example, “STATUS_LOGON_FAILURE”) is received, the CPU 32 determines that the Session Setup process has failed (NO in S62). Proceed to S100.

  The CPU 32 executes the Tree Connect process with the target server in S70, and determines whether or not the Tree Connect process was successful in S72. The CPU 32 determines that the Tree Connect process has been successful when the Tree Connect response is received from the target server in response to the transmission of the Tree Connect request to the target server in the Tree Connect process (YES in S72). Proceed to S80. On the other hand, when a Tree Connect response including a status other than the status “SUCCESS” (for example, “BAD_NETWORK_NAME”) is received in the Tree Connect process, the CPU 32 determines that the Tree Connect process has failed (NO in S72). The process proceeds to S100.

  In S80, the CPU 32 determines whether or not the version of the SMB protocol determined in the Negotiate process in S50 is “SMB2.1” or higher. The CPU 32 proceeds to S82 when the determined version is “SMB2.1” or higher (YES in S80), and proceeds to S82 when the determined version is “SMB2.0” or lower (NO in S80). , S84 are skipped, and the process proceeds to S90.

  In S82, the CPU 32 executes a Validate process with the target server, and determines in S84 whether the Validate process was successful. The CPU 32 determines that the Validate process was successful when the Validate Negotiate Info response is received from the target server in response to transmitting the Validate Negotiate Info request to the target server in the Validate process (YES in S84). Proceed to S90. On the other hand, when receiving the TCP RST signal from the target server, the CPU 32 determines that the Validate process has failed (NO in S84), and proceeds to S102.

  In S90, the CPU 32 executes profile registration. The CPU 32 registers the profile information including the network folder path, the user name, and the password in the test connection request in the profile table 38 in association with the profile name in the test connection request.

  In S100, the CPU 32 determines whether the failure of the Session Setup process or the Tree Connect process is a failure of the retest connection target. First, a case in which NO is determined in S62 will be described. When receiving a TCP RST signal and determining NO in S62, the CPU 32 determines that the retest connection target has failed (YES in S100), and proceeds to S102. On the other hand, if the CPU 32 receives a Session Setup response including a status other than the status “SUCCESS” (for example, “STATUS_LOGON_FAILURE”) and determines “NO” in S62, it determines that the retest connection target is not a failure. (NO in S100), the process of FIG. 11 ends. The status “STATUS_LOGON_FAILURE” is an error that is notified when a login name or a password is incorrectly input.

  Next, a case in which NO is determined in S72 will be described. When receiving a Tree Connect response including the status “INVALID_PARAMETER”, “USER_SESSION_DELETED”, or “ACCESS_DENIED” and determining “NO” in S72, the CPU 32 determines that the retest connection target has failed (S100). YES), and proceeds to S102. On the other hand, when receiving a Tree Connect response including the status “BAD_NETWORK_NAME” and determining NO in S72, the CPU 32 determines that the retest connection target is not a failure (NO in S100) and performs the processing in FIG. To end. Status "BAD_NETWORK_NAME" is an error that is notified when the network folder path is incorrectly entered.

  In other words, the failure determined as NO in S100 is a failure due to a user input error or the like, and the user can deal with the failure. On the other hand, the failure determined as YES in S100 is a failure due to something other than the user's input mistake. In this case, it is difficult for the user to deal with it. Therefore, when it is difficult for the user to cope with the situation, by performing the retest connection, the convenience for the user can be improved.

  In S102, the CPU 32 transmits a failure notification to the target PC. In S104, the CPU 32 determines whether a retest connection request has been received from the target PC. When a retest connection request is received from the target PC (YES in S104), the CPU 32 proceeds to S106. On the other hand, when the test connection stop request is received from the target PC (NO in S104), the CPU 32 ends the processing in FIG.

  In S106, the CPU 32 determines a version that is one older than the version of the SMB protocol used in the test connection with the target server as the version of the SMB protocol used in the retest connection with the target server, and returns to S50. . In this case, in the Negotiate process in S50, the CPU 32 transmits a Negotiate request including a version equal to or less than the version of the SMB protocol determined in S106 to the target server. In S90 after S106, the CPU 32 registers the version of the SMB protocol determined in S106 in the profile table 38 in association with the profile name in the test connection request.

(Effects of the present embodiment)
In the present embodiment, when receiving a Negotiate response including “SMB2.0” from the server 100E, the MFP 10 executes communication (Session Setup processing, Tree Connect processing) with the server 100E using “SMB2.0”. . In this communication, when receiving a Tree Connect response including the status “USER_SESSION_DELETED” from the server 100E (NO in S72), the MFP 10 transmits a Negotiate request including “SMB1.0” to the server 100E (after passing through S106). S50). When receiving a Negotiate response including “SMB1.0” from server 100E, MFP 10 communicates with server 100E using “SMB1.0” that is an older version than “SMB2.0” (Session Setup processing). , Tree Connect process). In this case, there is a high possibility that the MFP 10 does not receive a Tree Connect response including the status “USER_SESSION_DELETED” from the server 100E in the communication. Therefore, when a Tree Connect response including the status “USER_SESSION_DELETED” is received from the server 100E even though the negotiation has been normally performed, the MFP 10 can appropriately execute communication with the server 100E.

(Correspondence)
The MFP 10 and the PC 60 are examples of a “communication device” and a “third external device”, respectively. The SMB protocol is an example of the “predetermined communication protocol”. Profile information (folder path, user name, password) is an example of “first setting information”. The network folder path of the shared folder “shared51”, the user name in the authentication table of the server 100E, and the password are examples of “second setting information”. The scan instruction including the profile 5 and the scan instruction including the profile 4 are examples of the “first instruction” and the “second instruction”, respectively. The test connection request and the retest connection request are examples of “communication request” and “permission notification”, respectively. The first connection failure screen D7 and the second connection failure screen D8 are examples of the “version selection screen”.

  In one aspect, the server 100D and the server 100E are examples of a “first external device”. The Negotiate request of T460 of FIG. 6 and T660 of FIG. 7 is an example of the “first negotiation request”. The response including the TCP RST signal at T502 in FIG. 6 and the status “USER_SESSION_DELETED” at T682 in FIG. 7 is an example of “error notification”. The T530 in FIG. 6 and the Negotiate request in 710 in FIG. 7 are examples of the “second negotiation request”. SMB1.0 or SMB2.0 is an example of the “first version”. SMB 2.0 or SMB 2.1 is an example of the “second version”.

  T460 in FIG. 6 or T660 in FIG. 7 is an example of processing executed by the “first request transmission unit”. T480 to T502 in FIG. 6 and T670 to T682 in FIG. 7 are examples of processing executed by the “first communication execution unit”. T530 in FIG. 6 and T710 in FIG. 7 are examples of processing executed by the “second request transmitting unit”. T540 to T552 in FIG. 6 and T720 to T732 in FIG. 7 are examples of processing executed by the “second communication execution unit”.

  In another aspect, the server 100D and the server 100E are examples of a “first external device” and a “second external device”, respectively. SMB1.0, SMB2.0, and SMB2.1 are examples of “first version”, “second version”, and “third version”, respectively. The Negotiate request of T660 in FIG. 7, the Negotiate request of 710 in FIG. 7, the Negotiate request of T830 in FIG. 8, and the Negotiate request of T530 in FIG. 6 are respectively “first negotiation request” and “second negotiation request”. , "Third negotiation request", and "fourth negotiation request". A Negotiate request including only “SMB2.0” is an example of a “fifth negotiation request”.

  T660 in FIG. 7 is an example of processing executed by the “first request transmission unit”. T670 to T682 in FIG. 7 are an example of processing executed by the “first communication execution unit”. T710 in FIG. 7 is an example of a process executed by the “second request transmission unit”. T720 to T732 in FIG. 7 are an example of processing executed by the “second communication execution unit”.

  As described above, the specific examples of the present invention have been described in detail. However, these are merely examples and do not limit the scope of the claims. The technology described in the claims includes various modifications and changes of the specific examples illustrated above. Modifications of the above embodiment are listed below.

(Modification 1) A priority may be associated with each version in the version information included in the Negotiate request. In this modification, the server that has received the Negotiate request determines the version of the SMB protocol used for communication with the MFP 10 based on the priority of each version. For example, it is assumed that in the negotiate request of T660 in FIG. 7, the priority is set in the order of “SMB2.?”, “SMB2.0”, and “SMB1.0”. In this case, the server 100E determines that “SMB2.?” With the highest priority is unavailable, and determines that “SMB2.0” with the next highest priority is available. .0 ”is determined to execute communication with the MFP 10. Upon receiving the retest connection request from the PC 60 at T696, the MFP 10 determines that the test connection with the server 100D using “SMB2.1” has failed, and the MFP 10 is a version older than “SMB2.0”. The priority of “SMB1.0” is changed to the highest priority, and a Negotiate request including the version information associated with the changed priority is transmitted to the server 100E. That is, in the present modification, the Negotiate request of T710 includes the SMBs “2.?”, “SMB2.0”, and “SMB1.0”. In this case, the server 100E determines that “SMB1.0” having the highest priority is available, and determines to execute communication with the MFP 10 using “SMB1.0”. After that, the same processing as T710 to T742 is executed between the MFP 10 and the server 100E. With such a configuration, the same effect as that of the embodiment can be obtained.

(Modification 2) In the test connection process of FIG. 11, the CPU 32 may transmit a failure notification to the target PC regardless of the reason for failure. In this modification, S100 can be omitted.

(Modification 3) In S90 after S106 in FIG. 11, the CPU 32 does not have to register the SMB version. That is, in this modified example, the profile information of the profile table 38 does not include the SMB version. In this case, in case F of FIG. 8, processing similar to T660 to T682 and T710 to T732 of FIG. 7 is executed between the MFP 10 and the server 100E instead of the processing of T830 to T852, and thereafter , T860 to T864 are executed. That is, the “first storage control unit”, the “third request transmission unit”, the “second storage control unit”, and the “fifth request transmission unit” can be omitted.

(Modification 4) S22 to S26 in FIG. 10 can be omitted. That is, when a scan instruction is obtained, the CPU 32 may execute the processing of S30 to S34.

(Modification 5) In the test connection process of FIG. 11, if YES is determined in S100, the CPU 32 may not transmit a failure notification including the connection failure screen data to the target PC. In the present modification, the CPU 32 executes the process of S106 without receiving a retest connection request from the target PC. In this modification, S102 and S104 can be omitted. That is, the "screen data transmission unit" can be omitted.

(Modification 6) In the second connection failure screen D8, a message indicating that the security strength may be lowered may not be displayed.

(Modification 7) The “first external device” is not limited to a server, but may be any computer such as a PC that can create a shared folder.

(Modification 8) The “communication device” need not be the MFP 10 that can execute a plurality of functions, but may be a scanner device that can execute only a scan function.

(Modification 9) In the above embodiment, each process executed by the control unit 30 is realized by software (that is, the program 36). At least one of these processes is implemented by hardware such as a logic circuit. It may be realized.

  In addition, the technical elements described in the present specification or the drawings exhibit technical utility singly or in various combinations, and are not limited to the combinations described in the claims at the time of filing. The technology illustrated in the present specification or the drawings simultaneously achieves a plurality of objects, and has technical utility by achieving one of the objects.

2: communication system, 10: MFP, 12: operation unit, 14: display unit, 16: print execution unit, 18: scan execution unit, 20: communication I / F, 30: control unit, 32: CPU, 34: memory , 36: program, 38: profile table, 40: IP address, 100A to 100E: server, 110A: authentication table

Claims (14)

A communication device,
A communication interface;
A first request transmitting unit that transmits a first negotiation request including first version information to a first external device via the communication interface, wherein the first version information is Indicating that a plurality of versions of the predetermined communication protocol are available, wherein the plurality of versions includes a first version and a second version newer than the first version. 1, a request transmission unit,
In response to the first negotiation request being sent to the first external device, the first external device transmits the second version of the second version from the first external device via the communication interface. When a response indicating that the predetermined communication protocol is available is received, the communication with the first external device using the second version of the predetermined communication protocol is performed via the communication interface. A first communication execution unit that executes the first communication;
In the first communication, when an error notification is received from the first external device, a second negotiation including second version information different from the first version information via the communication interface A second request transmission unit that transmits a request to the first external device, wherein the second version information is such that the communication device can use the first version of the predetermined communication protocol. The second request transmission unit,
In response to the second negotiation request being transmitted to the first external device, the first external device uses the first version of the predetermined communication protocol from the first external device. And performing a second communication with the first external device using the first version of the predetermined communication protocol via the communication interface when a response indicating that the communication is possible is received. A second communication execution unit;
A communication device comprising:   The second version information indicates that the communication device uses the second version of the predetermined communication protocol even though the communication device can use the second version of the predetermined communication protocol. The communication device of claim 1, wherein the communication device does not indicate that it is possible.   The communication device according to claim 1, wherein the predetermined communication protocol is an SMB (abbreviation of Server Message Block) protocol. The first version is version 1.0 of the SMB protocol;
The communication device according to claim 3, wherein the second version is version 2.0 or more of the SMB protocol. The first communication includes a communication in which the communication device transmits a Validate Negotiation Info Request signal of the SMB protocol to the first external device via the communication interface,
The communication device according to claim 3, wherein the error notification is a signal indicating that the first external device cannot interpret the Validate Negotiation Info Request signal.   The communication device according to claim 5, wherein the error notification is a notification communicated using a lower layer protocol than the predetermined communication protocol in an OSI reference model. The first communication includes a communication in which the communication device transmits a Tree Connect Request signal of the SMB protocol to the first external device via the communication interface,
The communication device according to claim 3, wherein the error notification is a notification including any one of STATUS_USER_SESSION_DELETED, STATUS_INVALD_PARAMETER, and STATUS_ACCESS_DENIED. The first communication is first setting information used for communication of target data with the first external device, and the first setting information input by a user is the first setting information. Communication for confirming whether or not the second setting information stored in the device is compatible;
The second request transmission unit, when the error notification is a notification indicating that the first setting information does not conform to the second setting information, the second negotiation request to the first negotiation request The communication device according to claim 1, wherein the communication device does not transmit to an external device. The communication device may further include:
A first storage control unit that stores the first version in a memory of the communication device when a success notification is received from the first external device via the communication interface in the second communication; When,
In a state where the first version is stored in the memory, when a first instruction to execute communication of the target data with the first external device is obtained, A third request transmission unit that transmits a third negotiation request including third version information different from the first version information to the first external device, wherein the third version information includes: A third request transmission unit that indicates that the communication device can use the first version of the predetermined communication protocol stored in the memory;
The communication device according to any one of claims 1 to 8, comprising: The first storage control unit stores first external device information relating to the first external device and the first version in the memory in association with each other,
The plurality of versions further includes a third version newer than the second version;
The communication device may further include:
A third communication execution unit that executes a third communication with a second external device according to the third version of the predetermined communication protocol via the communication interface;
In the third communication, when the error notification is received from the second external device, a fourth negotiation request including fourth version information different from the first version information is sent to the second communication. A fourth request transmission unit that transmits to the external device, wherein the fourth version information indicates that the communication device can use the first and second versions of the predetermined communication protocol. The fourth request transmission unit;
In response to the fourth negotiation request being transmitted to the second external device, the second external device transmits the second version of the second version from the second external device via the communication interface. When a response indicating that the predetermined communication protocol is available is received, the communication with the second external device using the second version of the predetermined communication protocol is performed via the communication interface. A fourth communication execution unit that executes a fourth communication;
In the fourth communication, when a success notification is received from the second external device via the communication interface, the second external device information related to the second external device; A second storage control unit for storing the version of
In a state where the second external device information and the second version are stored in the memory in association with each other, a second instruction for executing target data communication with the second external device is issued. And when the second instruction including specifying the second external device information is obtained, a fifth negotiation request including fifth version information is transmitted to the second negotiation request via the communication interface. A fifth request transmitting unit for transmitting to the second external device, wherein the fifth version information is the predetermined version of the second version in which the communication device is associated with the second external device information. The fifth request transmission unit, indicating that the communication protocol of the fifth request can be used,
The third request transmission unit includes designating the first external device information in a state where the first external device information and the first version are stored in the memory in association with each other. When the first instruction is acquired, the second indication indicating that the communication device can use the first version of the predetermined communication protocol associated with the first external device information. The communication device according to claim 9, wherein the third negotiation request including version information of No. 3 is transmitted to the first external device. The communication device may further include:
Equipped with an operation unit,
The third request transmission unit,
In a state where the first version is stored in the memory, when the first instruction is obtained by performing a user operation on the operation unit, the third negotiation request is issued to the first negotiation request. To an external device,
In a state where the first version is stored in the memory, when the first instruction is obtained by performing an access to a web server in the communication device, the third negotiation request is issued. The communication device according to claim 9, wherein the communication device does not transmit to the first external device. The communication device may further include:
A request receiving unit that receives a communication request from a third external device different from the first external device via the communication interface;
The first request transmitting unit, when the communication request is received from the third external device, transmits the first negotiation request to the first external device,
The communication device may further include:
In the first communication with the first external device according to the second version of the predetermined protocol, when the error notification is received from the first external device, the first communication is performed via the communication interface. A screen data transmission unit for transmitting version selection screen data representing a version selection screen to the third external device, wherein the version selection screen uses a version older than the second version. Is a screen for allowing the user to select, comprising the screen data transmission unit,
The second request transmission unit receives, via the communication interface, a permission notification indicating that the user has selected to use the old version on the version selection screen from the third external device. The communication device according to any one of claims 1 to 11, wherein the communication device transmits the second negotiation request to the first external device when the request is issued.   The communication device according to claim 12, wherein the version selection screen includes a message indicating that a security level is reduced due to use of the old version. A computer program for a communication device,
A computer mounted on the communication device includes the following units:
A first request transmitting unit that transmits a first negotiation request including first version information to a first external device via a communication interface of the communication device, wherein the first version information is Indicating that the communication device is capable of using a plurality of versions of the predetermined communication protocol, wherein the plurality of versions include a first version and a second version newer than the first version. , The first request transmission unit,
In response to the first negotiation request being sent to the first external device, the first external device transmits the second version of the second version from the first external device via the communication interface. When a response indicating that the predetermined communication protocol is available is received, the communication with the first external device using the second version of the predetermined communication protocol is performed via the communication interface. A first communication execution unit that executes the first communication;
In the first communication, when an error notification is received from the first external device, a second negotiation including second version information different from the first version information via the communication interface A second request transmission unit that transmits a request to the first external device, wherein the second version information is such that the communication device can use the first version of the predetermined communication protocol. The second request transmission unit,
In response to the second negotiation request being transmitted to the first external device, the first external device uses the first version of the predetermined communication protocol from the first external device. And performing a second communication with the first external device using the first version of the predetermined communication protocol via the communication interface when a response indicating that the communication is possible is received. A second communication execution unit;
A computer program to function as.

Images