JP6358112B2 - Mediation server and computer program therefor - Google Patents

Description

  The present specification discloses a technique related to a mediation server for mediating service provision from a service provision server to a client device.

  Patent Document 1 discloses a system including a PC equipped with a web browser, a multi-function device (hereinafter referred to as “MFP”), a service providing device, and a relay device. In response to an instruction from the user, the PC transmits a temporary registration ID issue request to the relay device. In response to receiving the temporary registration ID issue request from the PC, the relay device generates a temporary registration ID and transmits the temporary registration ID to the PC. Thereby, since temporary registration ID is displayed in PC, the user can know temporary registration ID. Thereafter, the user operates the MFP to input a temporary registration ID into the MFP. In this case, the MFP transmits the temporary registration ID to the relay device. In response to receiving the temporary registration ID from the MFP, the relay device receives the access token from the service providing device, transmits the access token to the MFP, and registers the access token in the MFP. As a result, the MFP can receive the service from the service providing apparatus using the access token.

JP 2012-113696 A

  In the technique of Patent Document 1, the intermediary server generates a temporary registration ID in response to receiving a temporary registration ID issuance request from a PC, and then receives an access token in response to receiving the temporary registration ID from the MFP. Register with. That is, in order to register the access token in the MFP, the user needs to use the PC of the MFP and the PC first to generate a temporary registration ID in the relay device.

  In this specification, a technique is provided in which a user does not have to use a browser device of a client device and a browser device first in order to register an access token in the client device.

  The present specification discloses a computer program for an intermediary server. The computer program causes the computer of the mediation server to execute the following processes: a first trigger information generation process, an output process, a first trigger information acquisition process, a first access token acquisition process, a first The registration information supply process is executed. In the first trigger information generation process, first trigger information is generated in response to obtaining a request for generating first trigger information from a client device that is to receive service from one or more service providing servers. To do. The first trigger information is information that should be used as a trigger for the mediation server to acquire the first access token from a specific service providing server among the one or more service providing servers. In the output process, the first trigger information is output to the outside. In the first trigger information acquisition process, after the first trigger information is output to the outside, the browser device provided with the web browser supplies the first trigger information to the mediation server using the web browser. The first trigger information is acquired from the browser device. The browser device is different from the client device. In the first access token acquisition process, the first access token is acquired from the specific service providing server in response to acquiring the first trigger information from the browser device. In the first registration information supply process, the first registration information is supplied to the client device so that the first registration information including the first access token is registered in the client device. The first access token in the first registration information registered in the client device is information to be used for the client device to receive provision of a specific service from a specific service providing server.

  The above computer program can realize the following mediation server. The mediation server generates the first trigger information in response to acquiring the first trigger information generation request from the client device without acquiring the first trigger information generation request from the browser device. The first trigger information is output to the outside. Thereby, the user can know the first trigger information. Then, the mediation server acquires the first access token from the specific service providing server in response to acquiring the first trigger information from the browser device, and stores the first registration information including the first access token. Supply to client device. As a result, the first registration information is registered in the client device. As described above, according to the present technology, in order to register the access token in the client device, the user does not need to use the browser device of the client device and the browser device first. Can be improved.

  The mediation server itself and the mediation server control method realized by the computer program are also novel and useful. A communication system including a mediation server and at least one other device (for example, a client device or a browser device) is also new and useful. A computer-readable storage medium for storing the above computer program is also new and useful.

1 shows a configuration of a communication system. The sequence diagram of the case where a terminal device is used previously is shown. FIG. 3 shows a sequence diagram continued from FIG. 2. FIG. 4 shows a sequence diagram continued from FIG. 3. Each screen displayed on the terminal device is shown. Each screen displayed on the multi-function device is shown. The sequence diagram of the case where a multi-function device is used first is shown. FIG. 8 is a sequence diagram continued from FIG. 7. The sequence diagram following FIG. 8 is shown. FIG. 10 is a sequence diagram following FIG. 9. The sequence diagram of download printing and scan upload is shown. The sequence diagram of 2nd Example is shown.

(First embodiment)
(Configuration of communication system 2; FIG. 1)
As shown in FIG. 1, the communication system 2 includes a multi-function device 10, a mediation server 50, a terminal device 80, and a plurality of service providing servers 100 and 110. The devices 10 and the like are connected to the Internet 4 and can communicate with each other via the Internet 4. In this embodiment, an access token generated by a service providing server (for example, 100) is registered in the multi-function device 10, and the multi-function device 10 receives a service from the service providing server using the access token. Is realized. Hereinafter, the multi-function device and the service providing server are referred to as “MFP” and “SP server”, respectively.

(Configuration of MFP 10)
The MFP 10 can execute multiple functions including a print function, a scan function, and the like. The MFP 10 is a device connected to a LAN (abbreviation of Local Area Network) (not shown), and is a peripheral device of another apparatus (for example, a PC (abbreviation of Personal Computer)) connected to the LAN. The MFP 10 includes an operation unit 12, a display unit 14, a print execution unit 16, a scan execution unit 18, a network interface 20, and a control unit 30.

  The operation unit 12 includes a plurality of keys. The user can input various instructions to the multi-function device 10 by operating the operation unit 12. The display unit 14 is a display for displaying various information. The display unit 14 functions as a so-called touch panel. That is, the display unit 14 also functions as an operation unit operated by the user. The print execution unit 16 includes a printing mechanism such as an inkjet method or a laser method. The scan execution unit 18 includes a scan mechanism such as a CCD or CIS. The MFP 10 can be connected to the Internet 4 via the network interface 20 (that is, via a LAN).

  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 stores a service user table 38 in addition to the program 36 described above.

  In the service user table 38, one or more pieces of service user information are described. Each service user information is information in which a service ID, a display name, and an access token are associated. The service ID is information for identifying a service provided by the SP server (for example, 100), in other words, information for identifying the SP server. In this embodiment, the service ID of the SP server 100 and the service ID of the SP server 110 are “SID1” and “SID2”, respectively. The display name is a display name for a user who uses the MFP 10. The access token is authentication information for receiving service provision from the SP server.

  When the service user information is registered in the service user table 38, the multi-function device 10 can receive a service from an SP server (for example, 100) using the service user information. As will be described in detail later, the user can register the service user information in the service user table 38 by using the terminal device 80 of the MFP 10 and the terminal device 80 first (see FIGS. 2 to 4). The service user information can be registered in the service user table 38 using the MFP 10 first (see FIGS. 7 to 10).

(Configuration of Mediation Server 50)
The mediation server 50 is installed on the Internet 4 by the vendor of the MFP 10. The mediation server 50 mediates service provision from the SP servers 100 and 110 to the MFP 10.

  The mediation server 50 includes a network interface 60 and a control unit 70. The mediation server 50 is connected to the Internet 4 via the network interface 60. The control unit 70 includes a CPU 72 and a memory 74. The CPU 72 executes various processes according to the program 76 stored in the memory 74. The program 76 includes APIs (abbreviations for application program interfaces) corresponding to the service providing servers 100 and 110. Each API is a program for communicating with a service providing server corresponding to the API and executing data processing.

(Configuration of terminal device 80)
The terminal device 80 is a user terminal such as a PC, a mobile phone, or a smartphone. The terminal device 80 is connected to the Internet 4 via a LAN or a telephone line network such as 3G or 4G. The terminal device 80 includes a web browser 82, and executes communication with the mediation server 50 and the SP servers 100 and 110 using the web browser 82.

(Configuration of SP servers 100 and 110)
The SP servers 100 and 110 are servers having service names such as “Evernote (registered trademark)”, “Google (registered trademark) Docs”, “PICASA (registered trademark)”, “Facebook (registered trademark)”, for example. (That is, a cloud server). In the present embodiment, for simplification of description, the service name of the SP server 100 and the service name of the SP server 110 are described as “SVA” and “SVB”, respectively. Each of the SP servers 100 and 110 provides a service corresponding to the server to the communication device (for example, the MFP 10) via the Internet 4. Each SP server 100, 110 can provide various services to communication devices by executing various functions. For example, the SP server 100 provides a data storage service that acquires data from a communication device and stores the data, and a data supply service that supplies data in the server to the communication device.

(Case where terminal device 80 is used first; FIG. 2)
2 to 4, the service user information including the access token generated by the SP server 100 using the terminal device 80 of the MFP 10 and the terminal device 80 by the user first is obtained from the MFP 10. The process for registering with will be described. The user registers the account information AC in the SP server 100 before performing the operation for registering the service user information in the MFP 10. As a result, the account information AC is stored in the SP server 100 as indicated by X1 in FIG. The account information AC includes, for example, an account name and a password.

  2 and the subsequent processes may be described so that a plurality of pieces of information are collectively communicated between a pair of devices. For example, one request from one device to the other device may be described as including a plurality of pieces of information. However, in a modified example, a plurality of information may be sequentially communicated by performing communication of a plurality of requests and a plurality of responses between a pair of devices.

  In A <b> 1, the user activates the web browser 82 of the terminal device 80 and inputs a URL (abbreviation of Uniform Resource Locator) 50 </ b> A of initial screen data in the mediation server 50 to the terminal device 80. When the operation of A1 is executed by the user, in S10, the web browser 82 of the terminal device 80 supplies an initial screen request in which the input URL 50A is designated as the destination to the mediation server 50 via the Internet 4. . The initial screen request is a command for requesting supply of initial screen data. The terminal device 80 uses the web browser 82 to execute not only the process of S10 but also the following various processes. However, in the following, “the web browser 82 of the terminal device 80 executes...” Is simply described as “the terminal device 80 executes. In this embodiment, since all communication between the devices 10, 50, 80, 100 is communication via the Internet, the description “through the Internet” is omitted below.

  In response to acquiring an initial screen request from the terminal device 80, the CPU 72 of the mediation server 50 supplies initial screen data to the terminal device 80 in S12.

  In response to acquiring the initial screen data from the mediation server 50, the terminal device 80 displays the initial screen SC1 represented by the initial screen data in S14. FIG. 5 shows an initial screen SC1. The initial screen SC1 is a screen for selecting basic information related to the MFP 10. The basic information includes information indicating the country in which the MFP 10 is installed, information indicating the display language of the MFP 10, and information indicating the model name of the MFP 10. In A2 of FIG. 2, the user selects basic information (ie, country (eg, “US”), language (eg, “English”), and model name (eg, “ML1”)) while viewing the initial screen SC1. To the terminal device 80. When the operation of A2 is executed by the user, the terminal device 80 supplies a service screen request including the selected basic information to the mediation server 50 in S20. The service screen request is a command for requesting supply of service screen data.

  In response to obtaining the service screen request from the terminal device 80, the CPU 72 of the mediation server 50 generates service screen data according to the basic information in the server screen request. Specifically, the CPU 72 uses one or more SP servers installed in the country indicated by the basic information (hereinafter referred to as “installed SP server”) from a server table (not shown) stored in advance in the memory 74. Specified). In the server table, one or more installed SP servers are described for each of a plurality of countries. Next, the CPU 72 can provide a service to the MFP 10 having the model name indicated by the basic information among one or more specified installation SP servers from a model name table (not shown) stored in the memory 74 in advance. One or more SP servers (hereinafter referred to as “target SP servers”) are identified. In the server table, one or more target SP servers are described for each of a plurality of model names. Next, the CPU 72 generates service screen data representing a service screen indicating one or more service names corresponding to one or more specified target SP servers. Here, the CPU 72 generates service screen data representing a service screen in which one or more service names are described in the language indicated by the basic information. Next, in S <b> 22, the CPU 72 supplies the generated service screen data to the terminal device 80.

  In response to acquiring the service screen data from the mediation server 50, the terminal device 80 displays the service screen SC2 represented by the service screen data in S24. FIG. 5 shows a service screen SC2. The service screen SC2 is a screen for selecting one service name from one or more service names (“SVA”, “SVB”, “SVC” in the example of FIG. 5). In A3 of FIG. 2, the user performs an operation on the terminal device 80 to select one service name while viewing the service screen SC2. In the example of FIG. 2, the service name “SVA” of the SP server 100 is selected. When the operation of A3 is executed by the user, in S30, the terminal device 80 supplies a ReqT (abbreviation of Request Token) request including the selected service name “SVA” to the mediation server 50. The ReqT request is a command for requesting the supply of ReqT. ReqT is authentication information necessary to request the SP server 100 for login screen data (see S40 and S42), which will be described later.

  In response to acquiring the ReqT request from the terminal device 80, the CPU 72 of the mediation server 50 associates the service name “SVA” in the ReqT request from the service ID table (not shown) stored in advance in the memory 74. Specified service ID “SID1”. In the service ID table, for each of the plurality of SP servers 100 and 110, a service name of a service provided by the SP server and a service ID for identifying the service are associated with each other. In S31, the CPU 72 stores the specified service ID “SID1” in the memory 74 (see X2). Next, in S <b> 32, the CPU 72 supplies a ReqT request including the URL 50 </ b> B of the mediation server 50 to the SP server 100. Unlike the URL 50A input at A1, the URL 50B is a URL necessary for the terminal device 80 to supply an ID request (see S60 in FIG. 3) described later to the mediation server 50.

  In response to obtaining the ReqT request from the mediation server 50, the SP server 100 generates ReqT in S33. As a result, as indicated by X3, the SP server 100 associates the generated ReqT with the URL 50B in the ReqT request. Next, in S34, the SP server 100 supplies the mediation server 50 with a first response including ReqT and the URL 100A of the SP server 100. The first response is a response to the ReqT request in S32. The URL 100A is a URL necessary for the terminal device 80 to supply a later-described login screen request (see S40) to the SP server 100.

  In response to acquiring the first response from the SP server 100, the CPU 72 of the mediation server 50 supplies the terminal device 80 with a second response including the ReqT and the Redirect request in the first response in S36. . The redirect request includes the URL 100A in the first response as the redirect destination URL. The second response is a response to the ReqT request in S30.

  In response to acquiring the second response from the mediation server 50, the terminal device 80 sends a login screen request in which the URL 100A is designated as the destination to the SP server 100 in S40 according to the Redirect request in the second response. Supply. The login screen request includes ReqT in the second response. The login screen request is a command for requesting supply of login screen data.

  In response to acquiring the login screen request from the terminal device 80, the SP server 100 first determines whether or not ReqT in the login screen request is stored in the SP server 100 (that is, executes ReqT authentication). To do). When the SP server 100 determines that ReqT is stored in the SP server 100 (that is, when ReqT authentication is successful), the SP server 100 sends the login screen data to the terminal device 80 in S42. Supply.

  In response to acquiring the login screen data from the SP server 100, the terminal device 80 displays the login screen SC3 represented by the login screen data in S44. FIG. 5 shows a login screen SC3. The login screen SC3 is a screen for inputting account information AC including an account name and a password. When S44 ends, the process proceeds to FIG.

(Continuation of FIG. 2; FIG. 3)
In A4 of FIG. 3, the user performs an operation for inputting the account information AC on the terminal device 80 while viewing the login screen SC3. When the operation of A4 is performed by the user, in S50, the terminal device 80 supplies a login request including the input account information AC to the SP server 100. The login request is a command for requesting the terminal device 80 to log in.

  In response to acquiring the login request from the terminal device 80, the SP server 100 determines whether or not the account information AC in the login request is stored in the SP server 100 (that is, performs authentication of the account information AC). To do). In this case, in S51, the SP server 100 determines that the authentication of the account information AC has succeeded. Since the authentication of the account information AC is a process executed in response to a login screen request including ReqT (see S40 in FIG. 2), at this stage, in the SP server 100, the information X1 including the account information AC, and ReqT And the information X3 including the URL 50B are associated with each other. Further, in response to the successful authentication of the account information AC, the terminal device 80 is successfully logged in, that is, the login corresponding to the account information AC is successful (that is, the login state). Next, in S52, the SP server 100 generates AuthT (abbreviation of Authentication Token) different from ReqT. As a result, as indicated by X4, in the SP server 100, the account information AC in the information X1, Reqt in the information X3, the generated AuthT, and the URL 50B in the information X3 are associated with each other. AuthT is authentication information necessary for the mediation server 50 to supply an AccT (abbreviation of Access Token) request (see S92 in FIG. 4) described later to the SP server 100. Next, in S <b> 54, the SP server 100 supplies a login success notification including AuthT and a redirect request to the terminal device 80. The Redirect request includes the URL 50B (see X4) of the mediation server 50 associated with the account state AC that has been successfully logged in as the redirect destination URL.

  In response to acquiring the login success notification from the SP server 100, the terminal device 80 supplies an ID request in which the URL 50B is specified as the destination to the mediation server 50 in accordance with the Redirect request in the login success notification in S60. The ID request includes AuthT in the login success notification. The ID request is a command for requesting supply of a temporary ID (hereinafter referred to as “Temp (abbreviation for Temporary) ID”).

  In response to the acquisition of the ID request from the terminal device 80, the CPU 72 of the mediation server 50 generates a TempID that is a randomly determined character string in S61, and generates the generated TempID and the AuthT in the ID request. Store in the memory 74. As a result, as shown in X5, TempID, AuthT, and service ID “SID1” (see X2) are associated in the memory 74. Thus, since TempID and service ID “SID1” are associated with each other, when TempID is acquired from MFP 10 (see S80 in FIG. 4), service ID “SID1” associated with TempID is included. Service user information can be appropriately registered in the MFP 10. Next, in S <b> 62, the CPU 72 supplies the terminal device 80 with ID presentation screen data representing an ID presentation screen indicating TempID.

  In response to obtaining the ID presentation screen data from the mediation server 50, the terminal device 80 displays the ID presentation screen SC4 represented by the ID presentation screen data in S64. FIG. 5 shows an ID presentation screen SC4. ID presentation screen SC4 includes a character string “a1myy27a” indicating TempID and a message prompting the user to input TempID into MFP 10. Thus, the user can know TempID and can know that TempID should be input to the MFP 10. When S64 in FIG. 3 ends, the process for the user to use the terminal device 80 ends, and then the process proceeds to the process in FIG. 4 for the user to use the MFP 10.

(Continuation of FIG. 3; FIG. 4)
When the SP server 100 supplies the login success notification in S54 of FIG. 3, the SP server 100 deletes ReqT and URL 50B, which are unnecessary information in subsequent processing, from the information X4. As a result, the information X6 in FIG. 4 includes only the account information AC and AuthT.

  In A5 in FIG. 4, the user performs an operation on the MFP 10 to select an ID input button while viewing the registration main screen SC10 displayed on the display unit 14 of the MFP 10. FIG. 6 shows a registration main screen SC10. The registration main screen SC10 includes an ID input button indicating a character string “ID Input”, an ID issue button indicating a character string “ID Issue”, and a registration button indicating a character string “Register”. The ID input button is a button for inputting TempID in a case where the user uses the terminal device 80 first. The ID issuance button is a button for requesting issuance of TempID when the user uses the MFP 10 first. The registration button is a button for registering service user information when the user uses the MFP 10 first. When the operation of A5 is executed by the user, the CPU 32 of the MFP 10 supplies an ID input screen request to the mediation server 50 in S70. The ID input screen request is a command for requesting supply of ID input screen data.

  In response to the acquisition of the ID input screen request from the MFP 10, the CPU 72 of the mediation server 50 supplies the ID input screen data to the MFP 10 in S 72.

  In response to acquiring the ID input screen data from the mediation server 50, the CPU 32 of the MFP 10 supplies the ID input screen data to the display unit 14 and causes the display unit 14 to display the ID input screen SC11 in S74. FIG. 6 shows an ID input screen SC11. The ID input screen SC11 is a screen for inputting TempID. At A6 in FIG. 4, the user performs an operation on the MFP 10 for inputting the TempID known in S64 in FIG. 3 while looking at the ID input screen SC11. When the operation of A6 is executed by the user, the CPU 32 supplies a display name input screen request including the input TempID to the mediation server 50 in S80. The display name input screen request is a command for requesting supply of display name input screen data.

  In response to acquiring the display name input screen request from the MFP 10, the CPU 72 of the mediation server 50 first extracts information X 5 including TempID in the display name input screen request from the memory 74 of the mediation server 50. Thereby, thereafter, the CPU 72 executes each process (that is, S91, S92, S96, and S98 described later) using the information X5. In other words, the CPU 72 executes each of the above processes using the acquisition of TempID as a trigger. Next, in S <b> 82, the CPU 72 supplies display name input screen data to the MFP 10.

  In response to acquiring the display name input screen data from the mediation server 50, the CPU 32 of the MFP 10 supplies the display name input screen data to the display unit 14 and displays the display name input screen SC12 on the display unit 14 in S84. Let FIG. 6 shows a display name input screen SC12. The display name input screen SC12 is a screen for inputting a display name. In A7 of FIG. 4, the user performs an operation for inputting a desired display name on the MFP 10 while viewing the display name input screen SC12. When the operation of A7 is executed by the user, in S90, the CPU 32 supplies a registration information request including the input display name (“Alice” in the example of FIG. 4) to the mediation server 50. The registration information request is a command for requesting the supply of registration information.

  In response to acquiring the registration information request from the MFP 10, the CPU 72 of the mediation server 50 stores the display name “Alice” in the registration information request in the memory 74 in S 91. As a result, as indicated by X7, TempID, AuthT, service ID “SID1”, and display name “Alice” are associated in the memory 74. Next, in S92, the CPU 72 supplies an AccT request including AuthT in the information X7 to the SP server 100 corresponding to the service ID “SID1” in the information X7. The AccT request is a command for requesting supply of AccT.

  In response to acquiring the AccT request from the mediation server 50, the SP server 100 first determines whether or not the AuthT in the AccT request is stored in the SP server 100 (that is, performs AuthT authentication). . When the SP server 100 determines that AuthT is stored in the SP server 100 (that is, when AuthT authentication is successful), the SP server 100 generates AccT different from ReqT and AuthT in S93. As a result, the account information AC, AuthT, and the generated AccT are associated with each other in the SP server 100 as indicated by X8. Next, in S94, the SP server 100 supplies a response including AccT to the mediation server 50.

  In response to obtaining a response from the SP server 100, the CPU 72 of the mediation server 50 supplies the registration information RI1 to the MFP 10 in S96. The registration information RI1 includes a service ID “SID1” in the information X7, a display name “Alice” in the information X7, and AccT in the response. Next, in response to supplying the registration information RI1 to the MFP 10, the CPU 72 deletes the information X7 from the memory 74 in S98. Thereby, the memory 74 can be released.

  In response to acquiring the registration information RI1 from the mediation server 50, the CPU 32 of the MFP 10 registers the registration information RI1 in the service user table 38 (see FIG. 1) in the memory 74 in S100. Thereby, one new service user information in which the service ID “SID1”, the display name “Alice”, and AccT are associated is registered in the service user table 38. Therefore, thereafter, the CPU 32 can receive service from the SP server 100 using the service user information. Next, the CPU 32 supplies the registration completion screen data to the display unit 14 and causes the display unit 14 to display the registration completion screen SC13. Note that the registration completion screen data may be stored in advance in the memory 34 of the MFP 10 or may be acquired from the mediation server 50 together with the registration information RI1. FIG. 6 shows a registration completion screen SC13. Registration completion screen SC13 includes a message indicating that registration of service user information has been completed. When the process of S102 in FIG. 4 is completed, the process for registering the service user information in the MFP 10 using the terminal device 80 first ends.

(Case where MFP 10 is used first; FIG. 7)
Subsequently, referring to FIG. 7 to FIG. 10, the user registers the service user information including the access token generated by the SP server 100 in the MFP 10 by using the MFP 10 of the MFP 10 and the terminal device 80 first. The process for doing this will be described. In the following, for elements such as commands and screens having the same names as in FIGS. 2 to 6, description regarding the elements may be omitted, but the description of the elements is similar to the above description. As in the case of FIG. 2, the account information AC is stored in advance in the SP server 100 as indicated by X11.

  In A11, the user performs an operation on the MFP 10 to select an ID issue button while viewing the registration main screen SC10 (see FIG. 6) displayed on the display unit 14 of the MFP 10. The ID issue button is a button indicating a character string “ID Issue” (see SC10 in FIG. 6). When the operation of A11 is executed by the user, in S110, the CPU 32 of the MFP 10 supplies a service screen request including basic information (ie, country, language, model name) to the mediation server 50. The MFP 10 stores information indicating the country in which the MFP 10 is installed and information indicating the display language of the MFP 10 when the initial setting of the MFP 10 is executed (usually when the power of the MFP 10 is first turned on). 34 is stored. The memory 34 stores information indicating the model name of the MFP 10 in advance. That is, the memory 34 stores basic information in advance before the operation of A11 is executed. For this purpose, the CPU 32 supplies a service screen request including basic information in the memory 34 to the mediation server 50. As described above, in the case of FIG. 7, unlike the case of FIG. 2, the user does not have to select a country, a language, and a model name.

  In response to acquiring the service screen request from the MFP 10, the CPU 72 of the mediation server 50 generates service screen data according to the basic information in the server screen request. This process is the same as the process for generating service screen data in response to the service screen request in S20 of FIG. Next, in S <b> 112, the CPU 72 supplies the generated service screen data to the MFP 10.

  In response to acquiring the service screen data from the mediation server 50, the CPU 32 of the MFP 10 supplies the service screen data to the display unit 14 and displays the service screen SC21 on the display unit 14 in S114. FIG. 6 shows a service screen SC21. In A12 of FIG. 7, the user performs an operation on the MFP 10 for selecting one service name while viewing the service screen SC21. In the example of FIG. 7, the service name “SVA” of the SP server 100 is selected. When the operation of A12 is executed by the user, in S120, the CPU 32 supplies a display name input screen request including the selected service name “SVA” to the mediation server 50.

  In response to acquiring the display name input screen request from the MFP 10, the CPU 72 of the mediation server 50 changes the service name “SVA” in the display name input screen request from the service ID table (not shown) in the memory 74. The associated service ID “SID1” is specified. In S121, the CPU 72 stores the specified service ID “SID1” in the memory 74 (see X12). Next, in S <b> 122, the CPU 72 supplies display name input screen data to the MFP 10.

  In response to the acquisition of the display name input screen data from the mediation server 50, the CPU 32 of the MFP 10 supplies the display name input screen data to the display unit 14 and displays the display name input screen SC22 on the display unit 14 in S124. Let FIG. 6 shows a display name input screen SC22. In A13 of FIG. 7, the user performs an operation for inputting a desired display name on the MFP 10 while viewing the display name input screen SC22. When the operation of A13 is executed by the user, in S130, the CPU 32 displays the input display name (“Alice” in the example of FIG. 7), the MAC address of the MFP 10 (hereinafter referred to as “MAC”), An ID request including “” is supplied to the mediation server 50.

  In response to the acquisition of the ID request from the MFP 10, the CPU 72 of the mediation server 50 generates a TempID in S 131, the MAC in the ID request, the generated TempID, and the display name “Alice” in the ID request. Are stored in the memory 74. As a result, as shown in X13, the MAC, TempID, service ID “SID1” (see X12), and display name “Alice” are associated in the memory 74. In this way, since TempID and service ID “SID1” are associated with each other, the intermediary server 50 thereafter obtains TempID from the terminal device 80 (see S150 in FIG. 8), and the service associated with TempID. The URL 100A of the SP server 100 identified by the ID “SID1” can be appropriately supplied to the terminal device 80 (see S156 in FIG. 8). In addition, the mediation server 50 acquires the display name “Alice” from the MFP 10 instead of acquiring the display name from the terminal device 80. That is, the display name “Alice” is a character string input to the MFP 10, and includes characters that can be displayed by the MFP 10. Therefore, after that, when the service user information including the display name “Alice” is registered in the MFP 10 (see S220 in FIG. 10), the MFP 10 can appropriately display the display name “Alice”. Next, in S <b> 132, the CPU 72 supplies the terminal device 80 with ID presentation screen data representing an ID presentation screen indicating TempID.

  In response to acquiring the ID presentation screen data from the mediation server 50, the CPU 32 of the MFP 10 supplies the ID presentation screen data to the display unit 14 and displays the ID presentation screen SC23 on the display unit 14 in S134. FIG. 6 shows an ID presentation screen SC23. The ID presentation screen SC23 includes a character string “a1myy27a” indicating TempID, a character string indicating the URL 50C of the mediation server 50, and a message prompting the user to access the URL 50C using the web browser 82 and input the TempID. ,including. Thereby, the user can know TempID and can know that TempID should be input to the terminal device 80. The URL 50C is a URL necessary for the terminal device 80 to supply an ID input screen request (see S140 in FIG. 8) described later to the mediation server 50. When S134 in FIG. 7 ends, the process of using the MFP 10 by the user ends, and then the process proceeds to the process of FIG. 8 in which the user uses the terminal device 80.

(Continuation of FIG. 7; FIG. 8)
In A21 of FIG. 8, the user activates the web browser 82 of the terminal device 80, and inputs the URL 50C (see SC23 of FIG. 6) displayed in S134 of FIG. When the operation of A21 is executed by the user, in S140, the terminal device 80 supplies the intermediary server 50 with an ID input screen request in which the input URL 50C is specified as the destination.

  In response to acquiring the ID input screen request from the terminal device 80, the CPU 72 of the mediation server 50 supplies the ID input screen data to the terminal device 80 in S142.

  In response to acquiring the ID input screen data from the mediation server 50, the terminal device 80 displays the ID input screen SC31 represented by the ID input screen data in S144. FIG. 5 shows an ID input screen SC31. In A22 of FIG. 8, the user performs an operation on the terminal device 80 to input the TempID (see SC23 of FIG. 6) known in S134 of FIG. 7 while looking at the ID input screen SC31. When the operation of A22 is executed by the user, the terminal device 80 supplies a ReqT request including the input TempID to the mediation server 50 in S150.

  In response to acquiring the ReqT request from the terminal device 80, the CPU 72 of the mediation server 50 first extracts the information X13 including the TempID in the ReqT request from the memory 74 of the mediation server 50. Thus, thereafter, the CPU 72 executes each process (that is, S182 and S185 in FIG. 9 described later) using the information X13. In other words, the CPU 72 executes each of the above processes using the acquisition of TempID as a trigger. Next, in S <b> 152, the CPU 72 supplies a ReqT request including the URL 50 </ b> D of the mediation server 50 to the SP server 100. The URL 50D is a URL necessary for the terminal device 80 to supply a first AccT request (see S180 in FIG. 9) described later to the mediation server 50.

  S153 and S154 executed by the SP server 100 are the same as S33 and S34 in FIG. Thereby, as indicated by X14, ReqT and URL 50D are associated with each other in SP server 100. Further, S156 executed by the CPU 72 of the mediation server 50 is the same as S36 of FIG. Also, S160, S162, and S164 executed by the terminal device 80 are the same as S40, S42, and S44 in FIG. In S164, the login screen SC32 of FIG. 5 is displayed. When S164 in FIG. 8 ends, the process proceeds to FIG.

(Continuation of FIG. 8; FIG. 9)
A23 in FIG. 9 is the same as A4 in FIG. Further, S170, S171, S172, and S174 executed by the terminal device 80 and the SP server 100 are the same as S50, S51, S52, and S54 in FIG. As a result, the account information AC, ReqT, AuthT, and URL 50D are associated with each other in the SP server 100 as indicated by X15. Note that the login success notification in S174 includes the URL 50D in the information X15 as the redirect destination URL, unlike the login success notification in S52.

  In response to acquiring the login success notification from the SP server 100, the terminal device 80 sends the first AccT request in which the URL 50D is specified as the destination to the mediation server 50 in S180 according to the Redirect request in the login success notification. Supply.

  In response to the acquisition of the first AccT request from the terminal device 80, the CPU 72 of the mediation server 50 supplies the second AccT request including the Auth in the first AccT request to the SP server 100 in S182.

  S183 and S184 executed by the SP server 100 are the same as S93 and S94 in FIG. As a result, the account information AC, ReqT, AuthT, AccT, and URL 50D are associated in the SP server 100 as indicated by X16.

  In response to obtaining a response from the SP server 100, the CPU 72 of the mediation server 50 stores AccT in the memory 74 in S185. As a result, as shown in X17, the MAC, TempID, server ID “SID1”, display name “Alice”, and AccT are associated in the memory 74. Thus, since the server ID “SID1”, the display name “Alice”, and AccT are associated with each other, the mediation server 50 can appropriately register service user information including these pieces of information in the MFP 10 thereafter ( (See S212 and S220 in FIG. 10). Next, in S <b> 186, the CPU 72 supplies the storage notification screen data to the terminal device 80.

  In response to obtaining the storage notification screen data from the mediation server 50, the terminal device 80 displays the storage notification screen SC33 represented by the storage notification screen data in S188. FIG. 5 shows a storage notification screen SC33. Storage notification screen SC33 includes a message indicating that AccT has been stored in mediation server 50 and a message prompting the user to operate the registration button in MFP 10. Thus, the user can know that AccT is stored in the mediation server 50 and that the MFP 10 should operate the registration button. When S188 in FIG. 9 ends, the process of using the terminal device 80 by the user ends, and then the process proceeds to the process of FIG.

(Continuation of FIG. 9; FIG. 10)
When the SP server 100 supplies the response of S184 in FIG. 9, the ReqT, AuthT, and URL 50D, which are unnecessary information in the subsequent processing, are deleted from the information X16. As a result, the information X18 in FIG. 10 includes only the account information AC and AccT. In addition, when the CPU 72 of the mediation server 50 supplies the storage notification screen data in S186 of FIG. 9, the TempID that is unnecessary information in the subsequent processing is deleted from the information X17. As a result, the information X19 in FIG. 10 includes only the MAC, the service ID “SID1”, the display name “Alice”, and AccT.

  In A31, the user performs an operation on the MFP 10 to select a registration button while viewing the registration main screen SC10 (see FIG. 6) displayed on the display unit 14 of the MFP 10. The registration button is a button indicating the character string “Register” (see SC10 in FIG. 6). When the operation of A31 is executed by the user, the CPU 32 of the MFP 10 supplies a display name selection screen request including the MAC to the mediation server 50 in S200. The display name selection screen request is a command for requesting supply of display name selection screen data.

  The CPU 72 of the mediation server 50 generates display name selection screen data in response to acquiring a display name selection screen request from the MFP 10. Specifically, the CPU 72 extracts the display name “Alice” (see X19) associated with the MAC in the display name selection screen request from the memory 74, and uses the extracted display name “Alice” as an option. Display name selection screen data representing the display name selection screen to be included is generated. Note that, in the situation where the processing of FIGS. 7 to 9 has been executed by the user corresponding to another display name, the other display name is associated with the MAC. In this case, the CPU 72 generates display name selection screen data representing a display name selection screen including a plurality of display names including the display name “Alice” and the other display name as options. In step S <b> 202, the CPU 72 supplies the generated display name selection screen data to the MFP 10.

  In response to acquiring the display name selection screen data from the mediation server 50, the CPU 32 of the MFP 10 supplies the display name selection screen data to the display unit 14 and displays the display name selection screen SC41 on the display unit 14 in S204. Let FIG. 6 shows a display name selection screen SC41. The display name selection screen SC41 includes the display name “Alice” as an option. In A32 of FIG. 10, the user performs an operation on the MFP 10 to select the display name “Alice” while viewing the display name selection screen SC41. When the operation of A32 is executed by the user, the CPU 32 supplies a registration information request including the selected display name “Alice” to the mediation server 50 in S210.

  In response to acquiring the registration information request from the MFP 10, the CPU 72 of the mediation server 50 extracts information X 19 including the display name “Alice” in the registration information request from the memory 74. Next, in S212, the CPU 72 supplies the registration information RI2 to the MFP 10 using the extracted information X19. The registration information RI2 includes the service ID “SID1”, the display name “Alice”, and AccT in the information X19, and does not include the MAC in the information X19. As described above, when the mediation server 50 acquires the display name “Alice” in the information X19 from the MFP 10, the mediation server 50 supplies the registration information RI2 to the MFP 10 and registers service user information that matches the registration information RI2 in the MFP 10. Can do. That is, after the information X19 is stored in the memory 74, the mediation server 50 does not perform an operation for selecting the SP server 100 identified by the service ID “SID1” in the information X19 on the MFP 10 by the user. The registration information RI2 can be supplied to the MFP 10 so that service user information that matches the registration information RI2 can be registered in the MFP 10. Since the user does not need to select the SP server 100, the convenience for the user can be improved. Next, in response to supplying the registration information RI2 to the MFP 10, the CPU 72 deletes the information X19 from the memory 74 in S214. Thereby, the memory 74 can be released.

  In response to acquiring the registration information RI2 from the mediation server 50, the CPU 32 of the MFP 10 registers the registration information RI2 in the service user table 38 (see FIG. 1) in the memory 74 in S220. Thereby, one new service user information in which the service ID “SID1”, the display name “Alice”, and AccT are associated is registered in the service user table 38. Next, the CPU 32 supplies registration completion screen data to the display unit 14 and causes the display unit 14 to display a registration completion screen SC42. The registration completion screen data may be stored in advance in the memory 34 of the MFP 10 or may be acquired from the mediation server 50 together with the registration information RI2. FIG. 6 shows a registration completion screen SC42. When the process of S222 in FIG. 10 is completed, all processes for registering service user information in the MFP 10 using the MFP 10 first are completed.

  As described above, in this embodiment, the user can use the terminal device 80 first to register service user information in the MFP 10 (see FIGS. 2 to 4), or use the MFP 10 first. Thus, the service user information can be registered in the MFP 10 (see FIGS. 7 to 10). Hereinafter, the service user information registered in FIGS. 2 to 4 or 7 to 10 is referred to as “target service user information”. The MFP 10 can receive provision of various services from the SP server 100 in response to the registered target service user information being selected by the user. In the following, a case in which the MFP 10 downloads an image file from the SP server 100 (that is, receives provision of a data supply service) and executes printing (hereinafter referred to as “download printing”), and scans a document. The case of uploading the image file to the SP server 100 (that is, receiving the provision of the data storage service) will be sequentially described.

(Download printing; Fig. 11)
As indicated by X20 in FIG. 11, in the SP server 100, account information AC, AccT, and an image file F1 are associated with each other. The image file F1 is a file uploaded to the SP server 100 by the user in the process not shown.

  In A51, the user performs an operation on the MFP 10 to select target service user information from one or more pieces of service user information described in the service user table 38 (see FIG. 1) of the MFP 10. Although the operation of A51 is simply shown in FIG. 11, actually, before the operation of A51 is executed, the CPU 32 of the MFP 10 has one or more service IDs and 1 in the service user table 38. One or more display names are supplied to the mediation server 50. Then, the CPU 32 acquires service name selection screen data representing a service name selection screen including one or more service names corresponding to the one or more service IDs as options from the mediation server 50, and selects a service name. A screen is displayed on the display unit 14. In A51, the user selects the service name “SVA” of the SP server 100 on the service name selection screen. This is equivalent to the user selecting the service ID “SID1” in the target service user information. In addition, the CPU 32 acquires display name selection screen data representing a display name selection screen including one or more display names as options from the mediation server 50 and causes the display unit 14 to display the display name selection screen. In A51, the user selects the display name “Alice” on the display name selection screen. The CPU 32 sequentially supplies the selected service ID “SID1” and the selected display name “Alice” to the mediation server 50. In S250, the CPU 32 sends a first file URL request including AccT (that is, AccT in the target service user information) associated with the selected service ID “SID1” and the selected display name “Alice”. Supply to the mediation server 50. The first file URL request (and a second file URL request described later) is a command for requesting the supply of the URL of the image file F1.

  In response to the acquisition of the first file URL request from the MFP 10, the CPU 72 of the mediation server 50 supplies the SP server 100 with the second file URL request including AccT in the first file URL request in S252. .

  In response to acquiring the second file URL request from the intermediary server 50, the SP server 100 executes authentication of AccT in the second file URL request. In this case, AccT authentication is successful, and in S254, the SP server 100 supplies the mediation server 50 with the image file URL that is the URL of the image file F1 (see X20) associated with AccT.

  In response to obtaining the image file URL from the SP server 100, the CPU 72 of the mediation server 50 supplies the image file URL to the MFP 10 in S256.

  In response to obtaining the image file URL from the SP server 100, the CPU 32 of the MFP 10 supplies a download request in which the image file URL is designated as the destination to the SP server 100 in S260. The download request includes AccT in the target service user information. The download request is a command for requesting download (that is, supply) of the image file F1.

  The SP server 100 executes authentication of AccT in the download request in response to acquiring the download request from the MFP 10. In this case, AccT authentication is successful, and in S262, the SP server 100 supplies the mediation server 50 with the image file F1 (see X20) associated with AccT.

  In response to acquiring the image file F1 from the SP server 100, the CPU 32 of the MFP 10 executes printing of the image represented by the image file F1 in S264. Specifically, the CPU 32 converts the image file F <b> 1, generates print data that can be interpreted by the print execution unit 16, and supplies the print data to the print execution unit 16. As a result, the print medium on which the image represented by the image file F1 is printed can be provided to the user. Thereby, download printing ends.

(Scan upload; Fig. 11)
Next, the contents of scan upload will be described. As indicated by X21, in the SP server 100, account information AC and AccT are associated with each other.

  In A52, the user performs an operation on the MFP 10 to select the target service user information. The operation of A52 is the same as the operation of A51. When the operation of A52 is executed by the user, in S270, the CPU 32 of the MFP 10 supplies the first upload URL request including AccT to the mediation server 50. The first upload URL request (and a second upload URL request described later) is a command for requesting supply of a URL to which an image file is uploaded.

  In response to the acquisition of the first upload URL request from the MFP 10, the CPU 72 of the mediation server 50 supplies the second upload URL request including AccT in the first upload URL request to the SP server 100 in S <b> 272. .

  In response to acquiring the second upload URL request from the intermediary server 50, the SP server 100 executes authentication of AccT in the second upload URL request. In this case, AccT authentication is successful, and in S274, the SP server 100 generates an upload URL and supplies the upload URL to the mediation server 50.

  In response to obtaining the upload URL from the SP server 100, the CPU 72 of the mediation server 50 supplies the upload URL to the MFP 10 in S276.

  In response to the acquisition of the upload URL from the SP server 100, the CPU 32 of the MFP 10 causes the scan execution unit 18 to scan the original in S280, and uses the scan result obtained from the scan execution unit 18 to use the image file F2. Is generated. Next, in S290, the CPU 32 supplies the SP server 100 with an upload request in which the upload URL is designated as the destination. The upload request includes AccT in the target service user information and the generated image file F2. The upload request is a command for requesting upload (that is, storage) of the image file F2.

  The SP server 100 executes authentication of AccT in the upload request in response to acquiring the upload request from the MFP 10. In this case, AccT authentication is successful, and the SP server 100 stores the image file F2 in the upload request in association with AccT. Thereby, the scan upload is completed.

(Effect of this embodiment)
According to the present embodiment, the mediation server 50 generates a TempID (S131) in response to obtaining an ID request from the MFP 10 (S130 in FIG. 7) without obtaining an ID request from the terminal device 80. An ID presentation screen SC23 (FIG. 6) including TempID can be displayed on the MF 10 (S134 of FIG. 7). Thereby, the user can know TempID. Then, in response to obtaining the TempID from the terminal device 80 (S150 in FIG. 8), the mediation server 50 obtains AccT from the SP server 100 (S184 in FIG. 9), and sends the registration information RI2 including AccT to the MFP 10. Supply (S212 in FIG. 10). Thereby, the service user information that matches the registration information RI2 is registered in the MFP 10 (S220). Thus, according to the present embodiment, in order to register service user information including AccT in the MFP 10, the user does not have to use the terminal device 80 of the terminal device 80 and the MFP 10 first. For this reason, user convenience can be improved.

  Further, in response to acquiring the ID request from the terminal device 80 (S60 in FIG. 3), the mediation server 50 generates a TempID (S61), and displays the ID presentation screen SC4 (FIG. 5) including the TempID in the terminal device 80. (S64 in FIG. 2). Thereby, the user can know TempID. Then, in response to acquiring the TempID from the MFP 10 (S80 in FIG. 4), the mediation server 50 acquires AccT from the SP server 100 (S94), and supplies the registration information RI1 including AccT to the MFP 10 (S96). . As a result, service user information that matches the registration information RI1 is registered in the MFP 10 (S100). As described above, according to the present embodiment, the user can also register the service user information including AccT in the MFP 10 by using the terminal device 80 first. That is, the user can register the service user information in the MFP 10 regardless of which of the terminal device 80 and the MFP 10 is used first. For this reason, user convenience can be improved.

(Correspondence)
The MFP 10, the terminal device 80, and the SP server 100 are examples of “ client device”, “browser device”, and “specific service providing server”, respectively. The ID request in S130 and the TempID in S131 in FIG. 7 are examples of the “first trigger information generation request” and the “first trigger information”, respectively. The ID request in S60 and the TempID in S61 in FIG. 3 are examples of “second trigger information generation request” and “second trigger information”, respectively. The AccT in the response of S184 in FIG. 9 is an example of “first access token”. AccT in the response of S94 in FIG. 4 is an example of the “second access token”. The registration information RI2 in S212 of FIG. 10 is an example of “first registration information”. The registration information RI1 in S96 of FIG. 4 is an example of “second registration information”. The data supply service and data storage service provided by the SP server 100 in FIG. 11 are examples of “specific services”. The URL 100A in the second response in S156 of FIG. 8 is an example of “first URL”. The server name “SVA” in the display name input screen request in S120 of FIG. 7 and the service ID “SID1” stored in S121 of FIG. 7 are examples of “selection result information” and “specific server information”, respectively. is there. The display name “Alice” in the ID request in S130 of FIG. 7 and the MAC in the ID request are examples of “user name” and “device identification information”, respectively.

(Second embodiment; FIG. 12)
In this embodiment, the process for the user to use the MFP 10 first to register service user information in the MFP 10 (see FIGS. 7 to 10) is different from the first embodiment. In this embodiment, each process of FIG. 12 is executed instead of each process of FIG. The operations of A11 to A13 in FIG. 12 and the processes of S110 to S124 are the same as those in FIG. When the operation of A13 is executed by the user, in S300, the CPU 32 of the MFP 10 supplies an address input screen request including the input display name “Alice” to the mediation server 50. The address input screen request is a command for requesting supply of address input screen data.

  In response to the acquisition of the address input screen request from the MFP 10, the CPU 72 of the mediation server 50 stores the display name “Alice” in the address input screen request in the memory 74 in S 301. As a result, as indicated by X31, the service ID “SID1” (see X12) and the display name “Alice” are associated in the memory 74. In step S <b> 302, the CPU 72 supplies address input screen data representing the address input screen to the MFP 10.

  In response to acquiring the address input screen data from the mediation server 50, the CPU 32 of the MFP 10 supplies the address input screen data to the display unit 14 and displays the address input screen SC61 on the display unit 14 in S304. The address input screen SC61 is a screen for inputting a mail address for receiving an electronic mail. In A61, the user performs an operation on the MFP 10 for inputting the mail address MA set in the terminal device 80 while viewing the address input screen SC61. When the operation of A61 is executed, in S310, the CPU 32 supplies an ID request including the input mail address MA and MAC to the mediation server 50.

  In response to acquiring the ID request from the MFP 10, the CPU 72 of the mediation server 50 generates a TempID in S 311 and stores the MAC in the ID request and the generated TempID in the memory 74. As a result, as shown in X32, the MAC, TempID, service ID “SID1” (see X31), and display name “Alice” (see X31) are associated in the memory 74. Next, in S <b> 312, the CPU 72 transmits an e-mail EM including the text describing the target URL to the terminal device 80 with the mail address MA in the ID request of S <b> 310 as a transmission destination. The target URL is a URL for accessing the mediation server 50, and specifically, a destination URL for supplying a ReqT request (see S150 in FIG. 8) described later to the mediation server 50. The target URL includes a character string indicating the URL 50C of the mediation server 50 and a TempID as a query character string. The query character string is a character string after the character “?”. When S312 in FIG. 12 ends, the process of using the MFP 10 by the user ends, and then the process proceeds to the process of FIG. 8 in which the user uses the terminal device 80.

  After the terminal device 80 receives the email EM from the mediation server 50, the user performs an operation on the terminal device 80 for selecting the target URL described in the body of the email EM. Thus, without executing A21, S140 to S144, A22 of FIG. 8, in S150, the terminal device 80 supplies the ReqT request in which the selected target URL is designated as the destination to the mediation server 50. Since the query character string of the target URL includes TempID, the ReqT request includes TempID. The processes after S150 are the same as those in the first embodiment.

(Effect of this embodiment)
Also in this embodiment, since the service user information including AccT is registered in the MFP 10, the user does not need to use the terminal device 80 of the terminal device 80 and the MFP 10 first. For this reason, user convenience can be improved. If the user selects a target URL in the email EM, the terminal device 80 supplies a ReqT request including TempID to the mediation server 50 (T150 in FIG. 8). That is, it is not necessary for the user to perform operations (A21 and A22 in FIG. 8) for inputting the URL 50C and TempID to the terminal device 80. For this reason, user convenience can be improved. In the present embodiment, the target URL in the email EM is an example of “second URL”.

  Specific examples of the present invention have been described in detail above, but 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. For example, the following modifications are included.

(Modification 1) In each of the above embodiments, the mediation server 50 directly acquires AccT from the SP server 100 (S92 to S94 in FIG. 4 and S182 to S184 in FIG. 9). Instead, for example, the mediation server 50 supplies the MFP 10 with a predetermined instruction after S91 in FIG. 4, and executes the supply of the AccT request to the SP server 100 and the acquisition of the AccT from the SP server 100 to the MFP 10. After that, AccT may be acquired from the MFP 10. Further, for example, the mediation server 50 supplies a predetermined instruction to the terminal device 80 in response to acquiring the first AccT request in S180 of FIG. The supply and acquisition of AccT from the SP server 100 may be executed by the terminal device 80, and then AccT may be acquired from the terminal device 80. That is, the mediation server 50 may indirectly acquire AccT from the SP server 100 via the MFP 10 or the terminal device 80. Generally speaking, in the “first (or second) access token acquisition process”, the first (or second) access token may be directly acquired from a specific service providing server, or specified. The first (or second) access token may be obtained indirectly from the service providing server via the browser device (or client device).

(Modification 2) In S156 of FIG. 8, the mediation server 50 may supply the terminal device 80 with a second response that does not include the URL 100A of the SP server 100 (that is, the redirect mechanism may not be used). ). In this case, when the user of the terminal device 80 performs an operation of inputting the URL 100A to the terminal device 80, the terminal device 80 may supply the login screen request of S160 to the SP server 100. In this modification, the “URL supply process” can be omitted.

(Modification 3) In each of the above embodiments, service user information including the service ID “SID1”, the display name “Alice”, and AccT is registered in the MFP 10. However, in order for the MFP 10 to receive a service from the SP server 100, at least AccT needs to be registered in the MFP 10, and the service ID “SID1” and the display name “Alice” need not be registered in the MFP 10. In this case, for example, the mediation server 50 does not have to execute the process of acquiring the service name “SVA” from the MFP 10 in S120 of FIG. 7, and further performs the process of storing the service ID “SID1” in S121. It is not necessary to execute. Further, for example, the mediation server 50 does not have to execute the process of acquiring the display name “Alice” from the MFP 10 in S130 of FIG. 7, and further executes the process of storing the display name “Alice” in S131. You don't have to. In this modification, the “selection result information acquisition process”, “first storage control process”, “second storage control process”, “user name acquisition process”, and “third storage control process” are omitted. Is possible. Further, in the present modification, the “first registration information” may include only the first access token.

(Modification 4) In each of the above embodiments, the mediation server 50 acquires the MAC from the MFP 10 in S130 of FIG. 7, and stores the MAC in S131. Then, the mediation server 50 acquires the MAC from the MFP 10 in S200 of FIG. 10, and causes the MFP 10 to display a display name selection screen including the display name “Alice” associated with the MAC in S202 and S204. Instead of this, the mediation server 50 may not store the MAC. In other words, the information X19 may not include the MAC. Then, the mediation server 50 may execute the following instead of S200 to S210 in FIG. In other words, the mediation server 50 performs the operation of selecting the service name “SVA” and the operation of inputting the display name “Alice” on the MFP 10 by the user, so that the service name “ “SVA” and the input display name “Alice” may be acquired. Then, the mediation server 50 extracts AccT associated with the service ID “SID1” corresponding to the acquired service name “SVA” and the acquired display name “Alice” (see X19). The registration information RI2 including AccT may be supplied to the MFP 10. In this modification, the “device identification information acquisition process” and the “fourth storage control process” can be omitted.

(Modification 5) In each of the above embodiments, the mediation server 50 supplies the ID presentation screen data to the MFP 10 and displays the ID presentation screen SC23 on the MFP 10 in S132 of FIG. Instead, the mediation server 50 may supply the MFP 10 with print image data representing an image including TempID, and cause the MFP 10 to print the image. In this embodiment, the process of supplying print image data is an example of “output process”. The “output processing” may be replaced with, for example, “output processing for outputting the first trigger information to the outside in order to notify the user of the first trigger information”.

(Modification 6) In each of the above embodiments, the mediation server 50 may not be able to execute the processes of FIGS. That is, the mediation server 50 may not be able to execute a process for registering service user information including AccT in the MFP 10 in response to the user using the terminal device 80 first. In this modification, “second trigger information generation process”, “trigger information supply process”, “second trigger information acquisition process”, “second access token acquisition process”, and “second registration information” “Supply processing” can be omitted.

(Modification 7) In S312 of FIG. 12 of the second embodiment, the intermediary server 50 may transmit an email EM that includes a text in which TempID is described and a URL 50C is not described. . In this case, in response to the user of the terminal device 80 performing an operation for inputting the URL 50C and TempID on the terminal device 80, the terminal device 80 supplies a ReqT request to the mediation server 50 in S150 of FIG. Also good. In other words, the “e-mail” only needs to include at least the body text describing the first trigger information.

(Modification 8) The mediation server 50 may include two or more servers configured separately. For example, the mediation server 50 stores a first server for executing communication with each device 10, 80, 100, 110 and information (for example, information X7 in FIG. 4, information X17 in FIG. 9). And a second server. In this case, the first server accesses the second server and stores information in the second server or acquires information from the second server.

(Modification 9) The “client device” is not limited to the MFP 10, but is any other type of device (printer, scanner, FAX device, telephone device, PC, mobile phone, etc.) that should receive service from the service providing server. May be.

(Modification 10) In the above embodiment, the CPU 72 of the mediation server 50 executes the processing according to the program 76, thereby realizing the processing of FIGS. 2 to 4 and FIGS. Instead, at least one of these processes may be realized by hardware such as a logic circuit.

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

  2: communication system, 4: internet, 10: multi-function device (MFP), 12: operation unit, 14: display unit, 16: print execution unit, 18: scan execution unit, 20: network interface, 30: control unit, 32: CPU, 34: Memory, 36: Program, 38: Service user table, 50: Mediation server, 60: Network interface, 70: Control unit, 72: CPU, 74: Memory, 76: Program, 80: Terminal device 82: Web browser, 100, 110: Service providing server (SP server)

Claims (13)

A computer program for an intermediary server,
In the mediation server computer, each of the following processes:
First trigger information generation processing for generating the first trigger information in response to obtaining a request for generating the first trigger information from a client device that is to receive the service from one or more service providing servers The first trigger information is information to be used as a trigger for the mediation server to acquire a first access token from a specific service providing server among the one or more service providing servers. The first trigger information generation process,
An output process for outputting the first trigger information to the outside;
After the first trigger information is output to the outside, the browser device having a web browser supplies the first trigger information to the mediation server using the web browser, and the browser device A first trigger information acquisition process for acquiring the first trigger information from the browser device, wherein the browser device is different from the client device;
A first access token acquisition process for acquiring the first access token from the specific service providing server in response to acquiring the first trigger information from the browser device;
A first registration information supply process for supplying the first registration information to the client device so that the first registration information including the first access token is registered in the client device; The first access token in the first registration information registered in a device is information to be used for the client device to receive a specific service from the specific service providing server. A computer program for executing the first registration information supply process. The computer program is further stored in the computer.
In response to acquiring the first trigger information from the browser device, a URL supply process for supplying the browser device with a first URL indicating the position of login screen data in the specific service providing server is executed. ,
In the first access token acquisition process, after the browser device uses the web browser to access the login screen data indicated by the first URL and logs in to the specific service providing server. The computer program according to claim 1, wherein the first access token is acquired from the specific service providing server. The computer program is further stored in the computer.
A selection result information acquisition process for acquiring selection result information from the client device before generating the first trigger information, wherein the selection result information is stored in the client from the one or more service providing servers. The selection result information acquisition process, which is information indicating the specific service providing server selected by the user of the device;
In response to generating the first trigger information, the first trigger information is associated with specific server information for identifying the specific service providing server indicated by the selection result information, First storage control processing to be stored in the memory of the mediation server,
The URL supply process includes
Processing to extract the specific server information associated with the acquired first trigger information from the memory in response to acquiring the first trigger information from the browser device;
And a process of supplying the browser device with the first URL indicating the position of the login screen data in the specific service providing server identified by the extracted specific server information. The computer program described. The computer program is further stored in the computer.
A selection result information acquisition process for acquiring selection result information from the client device before generating the first trigger information, wherein the selection result information is stored in the client from the one or more service providing servers. The selection result information acquisition process, which is information indicating the specific service providing server selected by the user of the device;
A specific server for identifying the first access token and the specific service providing server indicated by the selection result information in response to obtaining the first access token from the specific service providing server And a second storage control process for associating and storing the information in the memory of the mediation server,
The first registration information supply process includes the first access token and the first server information associated with the first access token in the memory of the mediation server. Registration information is provided to the client device;
The specific server information in the first registration information registered in the client device, the client device, wherein the specific service providing server in order to receive the provision of the particular service is selected by the user The computer program according to any one of claims 1 to 3, which is information to be processed.   In the first registration information supply process, after the first access token and the specific server information are stored in the memory, the specific service providing server is selected from the one or more service providing servers. The computer program according to claim 4, wherein the first registration information including the first access token and the specific server information is supplied to the client device without being selected by the user. The computer program is further stored in the computer.
Before generating the first trigger information, a user name acquisition process for acquiring a user name input by a user of the client device from the client device;
A third storage control process for associating the first access token with the user name and storing the first access token in the memory of the mediation server in response to obtaining the first access token from the specific service providing server And execute
In the first registration information supply process, the first registration information including the first access token and the user name associated with the first access token in the memory of the mediation server. Is supplied to the client device,
The user name in the first registration information registered in the client device, the client device in order to receive the provision of a specific service from the specific service providing server, to be selected by the user The computer program according to any one of claims 1 to 5, which is information.   In the first registration information supply process, after the first access token and the user name are stored in the memory, the first access is performed in response to obtaining the user name from the client device. The computer program according to claim 6, wherein the first registration information including a token and the user name is supplied to the client device. The computer program is further stored in the computer.
Before generating the first trigger information, from the client device, and the device identification information acquisition process for acquiring device identification information for identifying said client device,
Fourth storage control for associating the first access token with the device identification information and storing the first access token in the memory of the mediation server in response to obtaining the first access token from the specific service providing server Process, and
In the first registration information supply process, after the first access token and the device identification information are stored in the memory, in response to obtaining the device identification information from the client device, The first registration information including the first access token associated with the device identification information and not including the device identification information is supplied to the client device. The computer program according to any one of claims 1 to 7.   The said output process WHEREIN: The said 1st trigger information is supplied to the said client apparatus so that the said 1st trigger information may be displayed on the said client apparatus, The Claim 1 any one of Claim 8 Computer program. The computer program is further stored in the computer.
An email address acquisition process for acquiring an email address from the client device;
The computer according to any one of claims 1 to 8, wherein, in the output process, an e-mail including a body in which the first trigger information is described is transmitted using the acquired mail address as a transmission destination. program. In the output process, the e-mail including the body in which a second URL for accessing the mediation server is described is transmitted using the acquired mail address as a transmission destination,
The computer program according to claim 10, wherein the second URL includes a character string indicating the first trigger information. The computer program is further stored in the computer.
In response to obtaining a request for generating second trigger information from the browser device, a second trigger information generating process for generating the second trigger information, wherein the second trigger information is The second trigger information generation process, which is information to be used as a trigger for the mediation server to acquire the second access token from the specific service providing server;
Trigger information supply processing for supplying the second trigger information to the browser device;
A second trigger information acquisition process for acquiring the second trigger information from the client device after supplying the second trigger information to the browser device;
A second access token acquisition process for acquiring the second access token from the specific service providing server in response to acquiring the second trigger information from the client device;
A second registration information supply process for supplying the second registration information to the client device so that the second registration information including the second access token is registered in the client device; The second access token in the second registration information registered in the device is information to be used for the client device to receive provision of the specific service from the specific service providing server. , The second registration information supply process;
The computer program according to claim 1, wherein the computer program is executed. An intermediary server,
A first trigger information generating unit that generates the first trigger information in response to obtaining a request for generating the first trigger information from a client device that is to receive the service from one or more service providing servers. The first trigger information is information to be used as a trigger for the mediation server to acquire a first access token from a specific service providing server among the one or more service providing servers. The first trigger information generator,
An output unit for outputting the first trigger information to the outside;
After the first trigger information is output to the outside, the browser device having a web browser supplies the first trigger information to the mediation server using the web browser, and the browser device A first trigger information acquisition unit for acquiring the first trigger information from the browser device, wherein the browser device is different from the client device;
A first access token acquisition unit for acquiring the first access token from the specific service providing server in response to acquiring the first trigger information from the browser device;
A first registration information supply unit configured to supply the first registration information to the client device so that the first registration information including the first access token is registered in the client device; The first access token in the first registration information registered in a device is information to be used for the client device to receive a specific service from the specific service providing server. The first registration information supply unit;
An intermediary server comprising

Images