JP2021196718A - Server device, system, control method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a server device, a system, a control method and a program for preventing a user who illegally obtains a URL from operating a shared target resource. SOLUTION: This is a system for securely sharing data of a service providing server, and a shared information management module 332 of an intermediary server 131 uses a first password set by a first device to share a service usage target. Receive and store the first password in association with the authorization information and the first usage identification information. Next, the shared folder access module 333 of the intermediary server 131 receives an access request transmitted from the second device and including the second usage identification information and the second password. The shared folder access module 333, which determines whether or not to allow access to the access request, sends the service to the usage target when the first usage identification information and the first password and the second usage identification information and the second password match. Allow access requests. [Selection diagram] Fig. 3

Description

The present invention relates to a system, a control method, and a program for securely sharing data of a service providing server.

There are data storage services that store data on the cloud, and such services are also required to share the stored data. When sharing data, both the sharing source user and the sharing destination user need to have an account in the data storage service.

However, for users who want to share the data of the data storage service only once, it is burdensome to create an account in the data storage service. Therefore, there is a conventional technique for issuing a URL for sharing the resource of the user U1 on the service providing server to the user U2 who has not registered an account in the service providing server (see Patent Document 1). In this prior art, an intermediary server that stores an access token for accessing a service providing server issues a URL for operating a shared target resource of the service providing server.

By this method, even a user who has not registered an account on the service providing server can operate the shared target resource as long as he / she knows the URL issued by the intermediary server.

Japanese Unexamined Patent Publication No. 2017-182466

Any user who knows the URL issued by the intermediary server can access the shared target resource, so that a user who illegally obtains the URL can operate the shared target resource.

The present invention has been made in view of the above-mentioned problems, and an object of the present invention is to prevent a user who illegally obtains a URL from operating a shared target resource.

In order to achieve the above object, the server device in the present invention corresponds to the client information based on the authorization information corresponding to the specific client information and the usage identification information for using the usage target of the service. A password receiving unit that is a server device that shares a usage target with a plurality of devices and receives a first password set by the first device to share the usage target, and authorizes the first password. A password storage unit that stores information in association with the first usage identification information, and an access request that is transmitted from the second device and includes access to the usage target and includes the second usage identification information and the second password. The access permission unit has an access request receiving unit for receiving the access request and an access permission unit for determining whether or not to allow access to the access request. The access permission unit includes the first usage identification information, the first password, and the first password. (Ii) When the usage identification information and the second password match, the access request is permitted.

According to the present invention, since a user who does not know the password cannot access the shared target resource, a user who illegally obtains the URL cannot access the shared target resource, and the security is improved.

It is a figure which shows the network configuration. It is a figure which shows the structure of the multifunction device and the intermediary server which concerns on 1st Embodiment. It is a figure which shows the module structure which concerns on 1st Embodiment. It is an access token issuance flow which concerns on 1st Embodiment. It is an access token issuance flow which concerns on 1st Embodiment. It is a flow to acquire the folder list from the service providing server which concerns on 1st Embodiment. This is a flow for sharing scan-uploaded data according to the first embodiment. This is a flow for sharing scan-uploaded data according to the first embodiment. It is a usage flow of the resource to be shared which concerns on 1st Embodiment. It is a usage flow of the resource to be shared which concerns on 1st Embodiment. It is a usage flow of the resource to be shared which concerns on 1st Embodiment. It is a shared target resource download and download mediation flow according to the first embodiment. This is an upload mediation flow according to the first embodiment. This is an example of various user input screens according to the first embodiment. It is a figure which shows the module structure which concerns on 2nd Embodiment. It is a client information registration flow which concerns on 2nd Embodiment. It is a usage flow of the resource to be shared which concerns on 2nd Embodiment. It is a usage flow of the resource to be shared which concerns on 2nd Embodiment. This is an access token refresh flow according to the second embodiment. This is an access token refresh flow according to the second embodiment. It is a figure which shows the module structure which concerns on 3rd Embodiment. It is an access token refresh flow of the device which concerns on 3rd Embodiment.

[First Embodiment]
Hereinafter, the first embodiment of the present invention will be described with reference to the drawings. The system according to the first embodiment is realized on a network having a configuration as shown in FIG. FIG. 1 is a diagram showing a network configuration. WAN100 is an abbreviation for Wide Area Network. In WAN100 of this embodiment, a World Wide Web (WWW) system is constructed. The WAN 100 is connected to each component by LAN 110, LAN 130, LAN 150, and LAN 170. LAN is an abbreviation for Local Area Network. The LAN 110 connects the WAN 100 and the multifunction device 111 (first device). The LAN 130 connects the WAN 100 and the intermediary server 131 (server device). The LAN 150 connects the WAN 100 and the service providing server 151. The LAN 170 connects the WAN 100 and the user terminal 171 (second device).

The multifunction device 111 is used by the user U1, and the service providing server 151 manages the resources of the user U1. As a result, the user U1 accesses the shared target resource on the service providing server 151 from the multifunction device 111, and saves the scanned image data. Here, in order for the multifunction device 111 to access the shared target resource on the service providing server 151, the user U1 who is the owner of the shared target resource needs to delegate the authority to the multifunction device 111. The service providing server 151 issues an access token (authorization information) as proof of access permission to the shared target resource to the multifunction device 111 according to the permission of the user U1. The access token corresponds to specific client information. The intermediary server 131 mediates access to the service providing server 151 from the multifunction device 111. Further, the intermediary server 131 provides a function for sharing the shared target resource of the user U1 with the user U2. The user terminal 171 is used by the user U2. The user terminal 171 is generally a PC, a mobile terminal, or the like, but may be another. The user U2 uses the shared target resource of the user U1 managed by the service providing server 151 from the user terminal 171 via the intermediary server 131. The shared target resource is the target for using the service in this embodiment.

The intermediary server 131 or the service providing server 151 may be configured on individual LANs or may be configured on the same LAN. Similarly, the intermediary server 131 or the service providing server 151 may be configured on the same PC or server computer. Further, although the intermediary server 131 and the service providing server 151 are each depicted as one in FIG. 1, a server system composed of a plurality of servers may be used. For example, a plurality of servers may be clustered to form an intermediary server 131. In the present embodiment, the term "server system" refers to a device that provides a specific service composed of at least one server.

The shared resource sharing system according to the first embodiment is realized on a system including a multifunction device 111 and a PC having a configuration as shown in FIG. FIG. 2 is a diagram showing the configuration of the multifunction device 111 and the intermediary server 131 according to the first embodiment. FIG. 2A is a diagram showing the configuration of the multifunction device 111 according to the present embodiment.

In FIG. 2A, the multifunction device 111 has a CPU 201. The CPU 201 executes a program stored in the program ROM of the ROM 203 or a program loaded into the RAM 202 from the external memory 211. Further, the CPU 201 controls each block connected to the system bus 204.

The image signal generated by the processing of the CPU 201 is output as output information to the printing unit (multifunction device engine) 209 via the printing unit I / F 206. Further, the CPU 201 can perform communication processing with the intermediary server 131 and the service providing server 151 via the input unit 205.

The control program of the CPU 201 and the like are stored in the program ROM in the ROM 203. The font data and the like used when generating the output information are stored in the font ROM in the ROM 203.

The RAM 202 is a RAM that functions as a main memory of the CPU 201, a work area, or the like. The RAM 202 is configured so that the memory capacity can be expanded by an optional RAM connected to an expansion port (not shown). Further, the RAM 202 is used for an output information expansion area, an environment data storage area, an NVRAM, and the like.

The external memory 211 is accessed by the memory controller (MC) 207, and stores font data, programs, form data, and the like. Further, the operation unit 210 is composed of a switch for operation, an LED display, and the like.

The scanner unit I / F 208 corrects, processes, and edits the image data received from the scanner unit 212. The scanner unit 212 converts the image information into an electric signal by inputting the reflected light obtained by exposing and scanning the image on the document to the CCD. Further, the electric signal is converted into a luminance signal composed of R, G, and B colors, and the luminance signal is read as image data.

When the user instructs the operation unit 210 to start scanning, the scanner unit 212 is instructed to read the document. Upon receiving this instruction, the scanner unit 212 performs a document reading operation. The method of reading the document may be in the form of an automatic feed method set in a document feeder (not shown). Further, a method of scanning the document by placing the document on a glass surface (not shown) and moving the exposed portion may be used.

In all the explanations described later, unless otherwise specified, the main body of the execution of the multifunction device 111 is the CPU 201. Further, the main body in the software is an application program installed in the external memory 211.

FIG. 2B is a diagram showing the configuration of the intermediary server 131 according to the first embodiment. The configuration of the intermediary server 131 shown in FIG. 2B is the same as the configuration of the service providing server 151 and the user terminal 171. The hardware block diagram shown in FIG. 2B is assumed to correspond to a hardware block diagram of a general information processing apparatus. Therefore, a general hardware configuration of an information processing device can be applied to the server computer and the terminal of the present embodiment.

In FIG. 2B, the CPU 251 executes a program such as an OS or an application. The program is stored in the program ROM of the ROM 253, or is loaded from the hard disk 261 to the RAM 252. Here, the OS is an abbreviation for an operating system running on a computer, and the operating system is hereinafter referred to as an OS.

The processing of each flowchart described later can be realized by executing the above program. The RAM 252 functions as a main memory, a work area, and the like of the CPU 251. The keyboard controller (KBC) 255 controls key input from the keyboard (KB) 259 and a pointing device (not shown). The CRT controller (CRTC) 256 controls the display of the CRT display 260. The disk controller (DKC) 257 controls data access on a hard disk (HD) 261 for storing various data, a floppy disk (registered trademark) disk (FD), and the like. NC258 is connected to the network and executes communication control processing with other devices connected to the network.

In all the explanations described later, unless otherwise specified, the main body on the hardware of the server computer and the user terminal is the CPU 251 and the main body on the software is the application program installed on the hard disk (HD) 261. .. The main body on the software is realized by the CPU 251 executing those programs.

FIG. 3 is a diagram showing a module configuration according to the first embodiment. FIG. 3A shows the module configuration of the multifunction device 111. The multifunction device 111 has an access token acquisition module 301, a folder list request module 302, a scan upload module 303, and a shared information registration module 304.

FIG. 3B shows the module configuration of the intermediary server 131. The mediation server 131 has a folder list acquisition module 331, a shared information management module 332, and a shared folder access module 333. Further, the mediation server 131 has a download data mediation module 334 and an upload data mediation module 335.

FIG. 3C shows a module configuration of the service providing server 151. The service providing server 151 has an access token issuing module 351, an accessability determination module 352, and a folder list transmission module 353. Further, the service providing server 151 has a download data transmission module 354 and an upload data storage module 355.

FIG. 3D shows a module configuration of the user terminal 171. The user terminal 171 has a shared folder access request module 371, a download request module 372, and an upload request module 373.

When issuing an access token according to these module configurations, the access token acquisition module 301 of the multifunction device 111 makes an access token issuance request. Here, the access token issuance request includes information on the user U1 who operates the multifunction device 111. The access token issuing module 351 of the service providing server 151 issues an access token in accordance with the access token issuing request of the multifunction device 111. At this time, the service providing server 151 confirms the permission of the authority transfer to the user U1 according to the user information of the user U1. When the user U1 permits the access token issuance request, the multifunction device 111 can acquire the access token from the service providing server 151. Further, the user U1 can access the shared target resource associated with the client information (account information) of the user U1 by using the access token acquired from the service providing server 151. Further, the access token is transmitted to the folder list acquisition module 331 of the intermediary server 131 by the folder list request module 302 of the multifunction device 111. As a result, the intermediary server 131 can access the shared target resource of the service providing server 151.

In the system of the present embodiment, it is possible to share the usage target corresponding to the specific client information to a plurality of devices. When the shared target resource of the user U1 is shared with the user U2, the shared information registration module 304 of the multifunction device 111 registers the shared information in the shared information management module 332 of the intermediary server 131. The shared information includes the access token, the information of the user U1, the information of the user U2, and the shared ID (use identification information) uniquely issued for each shared information. Next, the shared folder access module 333 of the intermediary server 131 receives the data access request (access request) from the user U2. Then, the shared folder access module 333 confirms whether the password is associated with the shared ID included in the data access request. Further, when a password is required, the shared folder access module 333 prompts the user terminal 171 used by the user U2 to input the password. When the password entered by the user U2 matches the password associated with the shared ID, the user terminal 171 can share the shared target resource of the service providing server 151.

4 and 5 are access token issuance flows according to the first embodiment. FIG. 4 is a flow in which the multifunction device 111 acquires an access token for accessing the service providing server 151. This flow is started when the multifunction device 111 accepts the service providing server use operation by the user U1.

In step S401, the access token acquisition module 301 transmits an authority delegation request to the access token issuing module 351 of the service providing server 151. This authority delegation request includes a client identifier of the multifunction device 111, a scope indicating the scope of delegation of authority, and a user identifier of the user U1 who is operating the multifunction device 111.

In step S402, the access token acquisition module 301 receives the authority delegation response from the access token issuing module 351 of the service providing server 151. This authority delegation response includes the delegation permission information issued by the access token issuing module 351.

In step S403, the access token acquisition module 301 determines whether or not the authority has been delegated from the authority delegation response received in step S402. If it is determined that the access token can be issued, the process proceeds to step S405. On the other hand, if it is determined that the access token cannot be issued, the process proceeds to step S404, the access token acquisition module 301 displays the authority transfer error screen on the multifunction device 111, and the flow ends.

In step S405, the access token acquisition module 301 transmits an access token issuance request to the access token issuance module 351 of the service providing server 151. The access token issuance request includes the delegation permission information and the client information received in step S402.

In step S406, the access token acquisition module 301 receives the access token issuance response from the access token issuance module 351 of the service providing server 151. This access token issuance response includes an access token issued by the access token issuance module 351.

In step S407, the access token acquisition module 301 determines whether the access token has been issued from the access token issuance response received in step S406. If the access token is issued, the process proceeds to step S408. On the other hand, if the access token is not issued, the process proceeds to step S410.

In step S408, the access token acquisition module 301 stores the access token received in step S406 in the access token management table. At the time of this storage, the access token acquisition module 301 associates the user identifier of the user U1 operating the multifunction device 111 with the access token.

Table 1 is an example of the access token management table stored in the access token acquisition module 301. Here, it means that the access token "AT1" is associated and stored with the user of the user identifier "Ken".

In step S409, the access token acquisition module 301 displays the access token issuance completion screen, and the flow ends. If the access token is not issued in step S407 described above, the access token acquisition module 301 displays an access token issuance error screen in step S410, and the flow ends.

FIG. 5A is a flow in which the service providing server 151 transfers authority according to the first embodiment. This flow is started when the access token issuing module 351 of the service providing server 151 receives the authority transfer request from the access token acquisition module 301 of the multifunction device 111.

In step S431, the access token issuing module 351 receives an authority delegation request from the access token acquisition module 301 of the multifunction device 111. This authority delegation request includes the client identifier and scope of the multifunction device 111, and the user identifier of the user U1 who is operating the multifunction device 111.

In step S432, the access token issuing module 351 identifies the user identifier from the authority delegation request received in step S431. Then, the authorization confirmation screen 1001 as shown in FIG. 14A is displayed for the user U1 and the authority delegation authorization is requested. The display content is determined with reference to the client identifier included in the authority delegation request received in step S431. Note that FIG. 14 is an example of various user input screens according to the first embodiment.

In step S433, the access token issuing module 351 determines whether the delegation of authority is permitted from the input content of the user U1 in step S432. If permitted, the process proceeds to step S434. On the other hand, if it is not permitted, the process proceeds to step S435.

In step S434, the access token issuing module 351 issues the delegation permission information. When issuing the delegation permission information, the access token issuing module 351 uses the client identifier and scope of the multifunction device 111 received in step S431, and the user identifier of the user U1 who is operating the multifunction device 111. Further, the access token issuing module 351 transmits the delegation permission information issued to the access token acquisition module 301 of the multifunction device 111, and the flow ends.

In step S435, the access token issuing module 351 sends a transfer failure notification to the access token acquisition module 301 of the multifunction device 111, and the flow ends.

FIG. 5B is a flow in which the service providing server 151 issues an access token according to the first embodiment. This flow is started when the access token issuing module 351 of the service providing server 151 receives the access token issuing request from the access token acquisition module 301 of the multifunction device 111.

In step S451, the access token issuing module 351 receives an access token issuance request from the access token acquisition module 301 of the multifunction device 111. This access token issuance request includes delegation permission information and client information.

In step S452, the access token issuing module 351 verifies the client information included in the access token issuing request received in step S451.

In step S453, the access token issuing module 351 determines whether the client information is correct from the verification result of step S452. If it is correct, the process proceeds to step S454. On the other hand, if it is not correct, the process proceeds to step S457.

In step S454, the access token issuing module 351 confirms whether the delegation is permitted from the delegation permission information and the client information included in the access token issuance request received in step S451.

In step S455, the access token issuing module 351 determines from the confirmation result of step S454 whether the delegation of authority is permitted. If permitted, the process proceeds to step S456. On the other hand, if it is not permitted, the process proceeds to step S457.

In step S456, the access token issuing module 351 issues an access token using the delegation permission information and the client information received in step S451. Further, the access token issued to the access token acquisition module 301 of the multifunction device 111 is transmitted, and the flow ends.

In step S457, the access token issuing module 351 sends an access token issuance failure notification to the access token acquisition module 301 of the multifunction device 111, and the flow ends.

FIG. 6 is a flow for acquiring a folder list from the service providing server 151 according to the first embodiment. FIG. 6A is a flow in which the multifunction device 111 receives the upload folder list. This flow is started when the multifunction device 111 accepts a service use operation by the user.

In step S501, the folder list request module 302 transmits an upload folder list request to the folder list acquisition module 331 of the mediation server 131. The upload folder list request includes the access token registered in the access token management table and the service name of the service providing server 151. The access token is registered in association with the user identifier of the user U1. The service name of the service providing server 151 is the one specified in the service use operation.

In step S502, the folder list request module 302 displays the upload folder selection screen 1002 as shown in FIG. 14B, and the flow ends. The upload folder selection screen 1002 is received as a response from the folder list acquisition module 331 of the mediation server 131.

FIG. 6B is a flow in which the mediation server 131 acquires the upload folder list. This flow is started when the folder list acquisition module 331 of the intermediary server 131 receives the upload folder list request from the folder list request module 302 of the multifunction device 111.

In step S511, the folder list acquisition module 331 receives the upload folder list request from the folder list request module 302 of the multifunction device 111. This upload folder list request includes an access token associated with the user identifier of the user U1 operating the multifunction device 111 and the service name of the service providing server 151 in which the shared resource is managed.

In step S512, the folder list acquisition module 331 transmits a folder list request to the folder list transmission module 353 of the service providing server 151 corresponding to the service name received in step S511. This folder list request includes the access token included in the upload folder list request and the identifier of the folder to be acquired.

In step S513, the folder list acquisition module 331 receives the folder list as a response from the folder list transmission module 353 of the service providing server 151.

In step S514, the folder list acquisition module 331 determines whether or not the folder list could be received from the response received in step S513. If it can be received, the process proceeds to step S515. On the other hand, if it cannot be received, the process proceeds to step S516.

In step S515, the folder list acquisition module 331 creates the upload folder selection screen 1002 using the folder list received in step S513. Further, the folder list acquisition module 331 sends the created upload folder selection screen 1002 to the folder list request module 302 of the multifunction device 111, and the flow ends.

In step S516, the folder list acquisition module 331 sends an inaccessible screen to the folder list request module 302 of the multifunction device 111, and the flow ends.

FIG. 6C is a flow in which the service providing server 151 returns the folder list. This flow is started when the folder list transmission module 353 of the service providing server 151 receives the folder list request from the folder list acquisition module 331 of the intermediary server 131.

In step S531, the folder list transmission module 353 receives the folder list request from the folder list acquisition module 331 of the mediation server 131. This folder list request includes an access token associated with the user identifier of the user U1 operating the multifunction device 111 and an identifier of the acquisition target folder.

In step S532, the accessability determination module 352 determines whether or not the folder list to be acquired can be accessed by using the access token included in the folder list request received in step S531.

In step S533, the accessability determination module 352 determines whether or not access is possible from the determination result of step S532. If access is possible, the process proceeds to step S534. On the other hand, if access is not possible, the process proceeds to step S535.

In step S534, the folder list transmission module 353 acquires the folder list designated as the acquisition target by using the access token received in step S531. Further, the folder list transmission module 353 transmits the acquired folder list to the folder list acquisition module 331 of the mediation server 131, and the flow ends.

In step S535, the folder list transmission module 353 transmits an inaccessibility notification to the folder list acquisition module 331 of the mediation server 131, and the flow ends.

7 and 8 are flows for sharing the scan-uploaded data according to the first embodiment. FIG. 7A is a flow in which the multifunction device 111 uploads scan data and sets the shared settings. This flow is started when the multifunction device 111 receives a scan upload instruction operation by the user.

In step S601, the scan upload module 303 receives a scan upload instruction from the user. This scan upload instruction may be given using a screen as shown in FIG. 14 (C). The scan upload instruction includes shared information including the address of the user U2 who is the sharer, the share target, the execution authority, and the password, the service name of the service providing server 151, and the identifier of the upload folder. Here, the sharing target is not limited to the image data.

In step S602, the scan upload module 303 performs a scan. As a result, the scan upload module 303 acquires the scan data.

In step S603, the scan upload module 303 transmits an upload request to the upload data storage module 355 of the service providing server 151. The upload request includes an access token, scan data acquired in step S602, and an identifier of the upload folder received in step S601. Here, the access token is associated with the user identifier of the user U1 as shown in the access token management table of Table 1.

In step S604, the scan upload module 303 receives the upload completion notification as a response from the upload data storage module 355 of the service providing server 151.

In step S605, the shared information registration module 304 acquires the shared information included in the scan upload instruction received in step S601.

In step S606, the shared information registration module 304 sends a shared information registration request to the shared information management module 332 of the intermediary server 131, and the flow ends. The shared information registration request includes the shared information acquired in step S606, the service name of the service providing server 151, the user identifier of the user U1 operating the multifunction device 111, and the access token associated with the user identifier. ..

FIG. 7B is a flow in which the intermediary server 131 registers the shared information and issues the shared URL. This flow is started when the shared information management module 332 of the intermediary server 131 receives the shared information registration request from the shared information registration module 304 of the multifunction device 111.

In step S621, the shared information management module 332 receives the shared information registration request from the shared information registration module 304 of the multifunction device 111. The shared information registration request includes shared information, a service name of the service providing server 151, a user identifier of the user U1 operating the multifunction device 111, an access token associated with the user identifier, and a password. In this way, the shared information management module 332 of the intermediary server 131 functions as a password receiving unit that receives the password (first password) set by the multifunction device 111 or associated with the access token.

In step S622, the shared information management module 332 creates a unique shared ID for each shared information.

In step S623, the shared information management module 332 associates the shared information, the service name, the user identifier of the user U1, the access token, and the password received in step S621 with the shared ID created in step S622 into the shared information management table. Remember. In this way, the shared information management module 332 of the intermediary server 131 functions as a password storage unit that stores the password in association with the access token and the shared ID (first usage identification information).

Table 2 is an example of the shared information management table stored in the shared information management module 332. Here, among the resources on the service name "SV1" that can be accessed by the user with the user identifier "Ken" using the access token "AT1", the information when sharing the shared target "F1" is stored in the shared information management table. Has been done. For the shared information whose shared ID is "SID1", refer to the shared sharer address xxx1 @ exact. A password "xxx" is set to allow com to execute "UL / DL". Further, the shared information whose shared ID is "SID2" is the shared person address xxx2 @ exact. The com is allowed to execute "DL", and the password is not set. Therefore, it is blank in Table 2. At this point, the user U1 can also set a password (first password) for the shared information whose shared ID is "SID2".

In step S624, the shared information management module 332 issues a shared URL for accessing the shared target. This shared URL includes the shared ID created in step S622.

In step S625, the shared information management module 332 sends an e-mail containing the shared URL issued in step S624 to the shared person address, and the flow ends. When the shared URL is notified to the user terminal 171 from the shared information management module 332 of the intermediary server 131, the password information is not described together. The password information is separately notified from the terminal used by the user U1 or the user U1 to the terminal used by the user U2 or the user U2.

FIG. 8 is a flow in which the service providing server 151 saves the data uploaded by the user U2. This flow is started when the upload data storage module 355 of the service providing server 151 receives an upload request from the scan upload module 303 of the multifunction device 111.

In step S641, the upload data storage module 355 receives an upload request from the scan upload module 303 of the multifunction device 111. The upload request includes the access token of user U1, the upload data, and the identifier of the upload folder.

In step S642, the accessability determination module 352 determines whether the upload folder can be accessed by using the access token included in the upload request received in step S641.

In step S643, the accessability determination module 352 determines whether or not access is possible from the determination result of step S642. If access is possible, the process proceeds to step S644. On the other hand, if access is not possible, the process proceeds to step S646.

In step S644, the upload data storage module 355 saves the upload data included in the upload request received in step S641 in the upload folder.

In step S645, the upload data storage module 355 sends an upload completion notification to the scan upload module 303 of the multifunction device 111, and the flow ends.

If access is not possible in step S643, the process proceeds to step S646. In step S646, the upload data storage module 355 sends an upload failure notification to the scan upload module 303 of the multifunction device 111, and the flow ends.

9 and 10 are a flow of using the shared target resource according to the first embodiment, and is a flow of returning a shared target screen in response to a data access request received by the intermediary server 131. This flow is started when the shared folder access request module 371 of the user terminal 171 accesses the shared URL at the request of the user U2.

In step S701, the shared folder access module 333 accesses the shared URL from the shared folder access request module 371 of the user terminal 171 and receives the data access request. This data access request includes a shared ID (second usage identification information) and a password (second password). In this way, the shared folder access module 333 of the intermediary server 131 functions as an access request receiving unit for receiving the access request transmitted from the user terminal 171.

In step S702, the shared folder access module 333 refers to the shared information management table shown in Table 2. Then, the shared folder access module 333 confirms whether or not the password is set in association with the shared ID included in the data access request received in step S701. In other words, it is determined whether or not the shared ID and password stored in step S623 and the shared ID and password received in step S701 match each other.

In step S703, the shared folder access module 333 determines whether or not the password has been set from the confirmation result of step S702. If a password has been set, the process proceeds to step S710. On the other hand, if the password is not set, the process proceeds to step S704. For example, when the shared ID is "SID1", the password is set, so the process proceeds to step S710. If the shared ID is "SID2", the password is not set, so the process proceeds to step S704. In this way, the shared folder access module 333 of the intermediary server 131 functions as an access permission unit for determining whether or not to allow access to the access request.

In step S704, the shared folder access module 333 transmits a password request to the shared folder access request module 371 of the user terminal 171. This password request includes a password confirmation screen 1004 as shown in FIG. 14 (D).

In step S705, the shared folder access module 333 receives the password request response from the shared folder access request module 371 of the user terminal 171. This password request response includes the password and the shared ID entered by the user U2.

In step S706, the shared folder access module 333 refers to the shared information management table shown in Table 2 and identifies the password associated with the shared ID included in the password request response received in step S705.

In step S707, the shared folder access module 333 refers to the shared information management table shown in Table 2. Then, the shared folder access module 333 confirms whether the password included in the password request response received in step S705 and the password specified in step S706 match.

In step S708, the shared folder access module 333 determines whether the password entered by the user U2 is correct from the determination result of step S707. If the password is correct, the process proceeds to step S710. On the other hand, if the password is incorrect, the process proceeds to step S709. For example, if the password included in the password request response received in step S705 is "xxx" and the password specified in step S706 is "xxx", the password is correct and the process proceeds to step S710. On the other hand, if the password included in the password request response received in step S705 is "aaa" and the password specified in step S706 is "xxx", the password is incorrect and the process proceeds to step S709.

In step S709, the shared folder access module 333 sends a password mismatch error screen to the shared folder access request module 371 of the user terminal 171, and the flow ends.

In step S710, the shared folder access module 333 refers to the shared information management table shown in Table 2, and obtains the access token associated with the shared ID included in the password request response received in step S705 and the identifier of the shared target. get.

In step S711, the folder list acquisition module 331 transmits a folder list request to the folder list transmission module 353 of the service providing server 151. This folder list request includes the access token acquired in step S710 and the identifier to be shared.

In step S712, the folder list acquisition module 331 receives the folder list as a response from the folder list transmission module 353 of the service providing server 151.

In step S713, the folder list acquisition module 331 determines whether or not the folder list could be received from the response received in step S712. If it can be received, the process proceeds to step S714. On the other hand, if it cannot be received, the process proceeds to step S715.

In step S714, the folder list acquisition module 331 creates the shared target screen 1005 as shown in FIG. 14 (E) by using the folder list received in step S712. Further, the folder list acquisition module 331 transmits the shared target screen 1005 to the shared folder access request module 371 of the user terminal 171, and the flow ends.

In step S715, the folder list acquisition module 331 sends an inaccessible screen to the shared folder access request module 371 of the user terminal 171, and the flow ends.

FIG. 11 is a flow for using the shared target resource according to the first embodiment, and is a flow for the user terminal 171 to use the data in the shared folder. This flow is started when the user terminal 171 accepts a shared URL access operation by the user.

In step S751, the shared folder access request module 371 sends a data access request to the shared folder access module 333 of the intermediary server 131 by accessing the shared URL notified to the user U2. This data access request includes a shared ID.

In step S752, the shared folder access request module 371 receives the password request from the shared folder access module 333 of the intermediary server 131. Further, the password confirmation screen 1004 included in this password request is displayed, and the input of the user U2 is requested.

In step S753, when the shared folder access request module 371 accepts the input operation of the user U2, the shared folder access request module 371 accesses the shared URL again. Further, the shared ID and the password entered by the user U2 are transmitted to the shared folder access module 333 of the intermediary server 131.

In step S754, the shared folder access request module 371 receives and displays the shared target screen 1005 as shown in FIG. 14 (E) from the folder list acquisition module 331 of the intermediary server 131.

In step S755, the shared folder access request module 371 accepts the input of the user U2. For example, the user U2 may download or upload the data “data001” in the “file / share / data” folder based on the screen display of FIG. 14 (E). When downloading, the user U2 selects the shared target "data001" on the display 901, selects the download radio button on the display 902, and specifies the save destination folder for saving the downloaded data on the display 903. On the other hand, when uploading, the user U2 selects the shared target "file001" on the display 901, selects the upload radio button on the display 904, and specifies the data to be uploaded on the display 905.

In step S756, the shared folder access request module 371 determines whether to execute the upload or download function from the contents input from the user U2 in step S755. When downloading, the process proceeds to step S757, and when uploading, the process proceeds to step S759. For example, when the download radio button is selected from the user U2 on the display 902, the process proceeds to step S757 for downloading. When the upload radio button of the display 904 is selected from the user U2, the process proceeds to step S759 for uploading.

In step S757, the download request module 372 sends a data download request to the download data mediation module 334 of the mediation server 131. This data download request includes an identifier to be downloaded and a shared ID. Here, the download target is not limited to the image data.

In step S758, the download request module 372 receives a response from the download data mediation module 334 of the mediation server 131, and the flow ends.

In step S759, the upload request module 373 sends a data upload request to the upload data mediation module 335 of the mediation server 131. The data upload request includes the upload data, the upload folder identifier, and the shared ID. Here, the uploaded data is not limited to the image data.

In step S760, the upload request module 373 receives a response from the upload data mediation module 335 of the mediation server 131, and the flow ends.

FIG. 12 is a shared target resource download and download mediation flow according to the first embodiment. FIG. 12A is a flow in which the mediation server 131 downloads the data in the shared folder. This flow is started when the download data mediation module 334 of the mediation server 131 receives a data download request from the download request module 372 of the user terminal 171.

In step S801, the download data mediation module 334 receives a data download request from the download request module 372 of the user terminal 171. This data download request includes an identifier to be downloaded and a shared ID.

In step S802, the download data mediation module 334 refers to the shared information management table shown in Table 2. Then, the download data mediation module 334 acquires the access token and the service name associated with the shared ID included in the data download request received in step S801.

In step S803, the download data mediation module 334 sends a download request. Here, the download request is transmitted to the download data transmission module 354 of the service providing server 151 that provides the service of the service name acquired in step S802. This download request includes the access token identified in step S802 and the identifier of the download target included in the data download request received in step S801.

In step S804, the download data mediation module 334 receives a response from the download data transmission module 354 of the service providing server 151.

In step S805, the download data mediation module 334 determines whether the response received in step S804 includes download data. If the download data is included, the process proceeds to step S806. On the other hand, if the download data is not included, the process proceeds to step S807.

In step S806, the download data mediation module 334 transmits the download data received in step S804 to the download request module 372 of the user terminal 171, and the flow ends.

In step S807, the download data mediation module 334 sends a download failure screen to the download request module 372 of the user terminal 171, and the flow ends.

FIG. 12B is a flow for transmitting the data downloaded by the service providing server 151. This flow is started when the download data transmission module 354 of the service providing server 151 receives the download request from the download data mediation module 334 of the mediation server 131.

In step S821, the download data transmission module 354 receives the download request from the download data mediation module 334 of the mediation server 131. This download request includes an access token and an identifier to be downloaded.

In step S822, the accessability determination module 352 determines whether or not the download target can be accessed by using the access token included in the download request received in step S821.

In step S823, the accessability determination module 352 determines whether or not access is possible from the determination result of step S822. If access is possible, the process proceeds to step S824. On the other hand, if access is not possible, the process proceeds to step S825.

In step S824, the download data transmission module 354 transmits the download data to the download data mediation module 334 of the mediation server 131, and the flow ends.

In step S825, the download data transmission module 354 transmits a download failure notification to the download data mediation module 334 of the mediation server 131, and the flow ends.

FIG. 13 is an upload mediation flow according to the first embodiment, and shows a flow in which the mediation server 131 uploads data to the shared folder. This flow is started when the upload data mediation module 335 of the mediation server 131 receives a data upload request from the upload request module 373 of the user terminal 171.

In step S841, the upload data mediation module 335 receives a data upload request from the upload request module 373 of the user terminal 171. The data upload request includes the upload data, the upload folder identifier, and the shared ID.

In step S842, the upload data mediation module 335 refers to the shared information management table shown in Table 2. Then, the upload data mediation module 335 specifies an access token associated with the shared ID included in the data upload request received in step S841.

In step S843, the upload data mediation module 335 sends an upload request to the upload data storage module 355 of the service providing server 151. This upload request includes the access token specified in step S842, the upload data included in the data upload request received in step S841, and the identifier of the upload folder.

In step S844, the upload data mediation module 335 receives a response from the upload data storage module 355 of the service providing server 151.

In step S845, the upload data mediation module 335 determines whether the upload is completed from the response received in step S844. When the upload is completed, the process proceeds to step S846. On the other hand, if the upload is not completed, the process proceeds to step S847.

In step S846, the upload data mediation module 335 sends an upload completion screen to the upload request module 373 of the user terminal 171, and the flow ends.

In step S847, the upload data mediation module 335 sends an upload failure screen to the upload request module 373 of the user terminal 171, and the flow ends.

According to the first embodiment, when the shared ID and password associated with the access token in advance and the shared ID and password included in the access request from the user terminal 171 match, the access request is permitted. .. As a result, a user who does not know the shared ID and password cannot access the shared resource. Therefore, for example, a user who illegally obtains the URL cannot access the shared target resource. This improves the security of the system.

[Second Embodiment]
Hereinafter, the second embodiment of the present invention will be described with reference to the drawings. The parts common to the first embodiment will be omitted, and only the differences will be described below. When the resource of the user U1 on the service providing server 151 is shared with the user U2, the access token may expire before the user U2 operates the shared target resource. In this case, the user U2 may not be able to access the data. This embodiment has been made in view of this problem.

FIG. 15 is a diagram showing a module configuration according to the second embodiment. FIG. 15A shows a module of the multifunction device 111. The multifunction device 111 of this embodiment has a client information registration module 1011.

FIG. 15B shows the module configuration of the intermediary server 131. The mediation server 131 of the present embodiment has a client information management module 1031 and an access token refresh request module 1032.

FIG. 15C shows a module configuration of the service providing server 151. The service providing server 151 of this embodiment has an access token refresh module 1051.

A case where the user U2 refreshes the access token for accessing the shared target resource by these module configurations will be described. When refreshing the access token, the client information registration module 1011 of the compound machine 111 registers the client information in the client information management module 1031 of the intermediary server 131. The client information includes a client ID and a secret used by the multifunction device 111 for issuing or refreshing an access token. The access token refresh module 1051 of the service providing server 151 performs the validity confirmation and refresh processing of the access token in response to the request of the access token refresh request module 1032 of the intermediary server 131.

FIG. 16 is a client information registration flow according to the second embodiment. FIG. 16A is a flow in which the multifunction device 111 transmits client information to the intermediary server 131. This flow is started by accepting from the user an operation of registering information for using the service of the service providing server 151 in the intermediary server 131 from the multifunction device 111.

In step S1101, the client information registration module 1011 transmits a client information registration request to the client information management module 1031 of the intermediary server 131. This client information registration request includes the client ID and secret of the multifunction device 111.

In step S1102, the client information registration module 1011 receives a response from the client information management module 1031 of the intermediary server 131, and the flow ends.

FIG. 16B is a flow in which the intermediary server 131 registers client information. This flow is started when the client information management module 1031 of the intermediary server 131 receives the client information registration request from the client information registration module 1011 of the compound machine 111.

In step S1121, the client information management module 1031 receives the client information registration request from the client information registration module 1011 of the multifunction device 111. This client information registration request includes the client ID and secret of the multifunction device 111.

In step S1122, the client information management module 1031 stores the client ID and secret included in the client information registration request received in step S1121 in the client authentication information table. Therefore, the client information management module 1031 functions as a client information storage unit that stores the client information of the multifunction device 111.

Table 3 is an example of the client authentication information table stored in the client information management module 1031. Here, it means that the secret "secret001" is associated with the client of the client ID "clinent_aa" and stored. Similarly, the secret "secret002" is associated with and stored in the client of the client ID "clinent_bb". Further, the secret "secret003" is associated with the client of "client_cc" and stored.

In step S1123, the client information management module 1031 notifies the client information registration module 1011 of the multifunction device 111 of the completion of registration, and the flow ends.

17 and 18 are the usage flow of the shared target resource according to the second embodiment, and are the second flow of returning the shared target screen in response to the data access request received by the intermediary server 131. In this flow, in step S708 of FIG. 10 in the first embodiment, step S1201 is performed after the password is determined to be correct. The steps already described in the first embodiment will be omitted.

In step S1201, the access token refresh request module 1032 refers to the shared information management table shown in Table 2. Then, the access token refresh request module 1032 specifies the access token associated with the shared ID included in the password request response received in step S705.

In step S1202, the access token refresh request module 1032 transmits an access token update request to the access token refresh request module 1032 of the intermediary server 131. The access token update request includes the access token identified in step S1201. When the update of the access token is completed, the process proceeds to step S710 and the process is continued.

FIG. 19 is an access token refresh flow according to the second embodiment, and shows a flow in which the intermediary server 131 updates the access token. This flow is started when the access token refresh request module 1032 of the intermediary server 131 receives the access token update request.

In step S1301, the access token refresh request module 1032 receives an access token update request from the access token refresh request module 1032 of the intermediary server 131. This access token update request includes an access token.

In step S1302, the access token refresh request module 1032 transmits an access token validity confirmation request to the access token refresh module 1051 of the service providing server 151. The access token validity confirmation request includes the access token included in the access token update request received in step S1301.

In step S1303, the access token refresh request module 1032 receives the validity confirmation response from the access token refresh module 1051 of the service providing server 151.

In step S1304, the access token refresh request module 1032 determines whether the access token is valid from the validity confirmation response received in step S1303. If the access token is valid, the process proceeds to step S1311. On the other hand, if the access token is invalid, the process proceeds to step S1305.

In step S1305, the access token refresh request module 1032 refers to the shared information management table as shown in Table 4. Then, the access token refresh request module 1032 specifies the refresh token and the client ID registered in association with the access token received in step S1301.

Table 4 is an example of a shared information management table. In Table 4, the information when the users of the user identifiers “Ken” and “Tom” share the resource on the service name “SV1” is stored in the shared information management table. In SID1 and SID2, Ken shares the shared object "F1" using the access token "AT1", and in SID3, Ken shares the shared object "F2" using the access token "AT2". Further, in SID4, Tom shares the sharing target "F3" by using the access token "AT3".

In step S1306, the access token refresh request module 1032 refers to the client authentication information table shown in Table 3. Then, the access token refresh request module 1032 specifies the secret registered in association with the client ID specified in step S1305.

In step S1307, the access token refresh request module 1032 transmits an access token refresh request to the access token refresh module 1051 of the service providing server 151. The access token refresh request includes the refresh token and the client ID specified in step S1305, and the secret specified in step S1306.

In step S1308, the access token refresh request module 1032 receives the latest access token and refresh token from the access token refresh module 1051 of the service providing server 151.

In step S1309, the access token refresh request module 1032 identifies the information associated with the access token received in step S1301 from the shared information management table in Table 4. Further, the update is performed with the latest access token and refresh token received in step S1308. For example, it is assumed that as a result of refreshing the access token "AT1" using the refresh token "RT1", a new access token "AT10" and a refresh token "RT10" are received in step S1308. When the information associated with AT1 is updated by AT10 and RT10, the access tokens and refresh tokens of SID1 and SID2 associated with AT1 are updated to AT10 and RT10, respectively. On the other hand, the information of SID3 and SID4 not associated with AT1 is not updated. In this way, the access token refresh request module 1032 functions as an authorization information update unit that updates the authorization information managed in association with the shared ID.

In step S1310, the access token refresh request module 1032 returns the latest access token and refresh token received in step S1308. The destination where the access token refresh request module 1032 returns the latest access token and the refresh token is the access token refresh request module 1032 of the intermediary server 131. This ends the flow.

In step S1311, the access token refresh request module 1032 returns the access token received in step S1301. The destination where the access token refresh request module 1032 returns the access token is the access token refresh request module 1032 of the intermediary server 131. This ends the flow.

FIG. 20 is an access token refresh flow according to the second embodiment. FIG. 20A is a flow for confirming whether the access token received by the service providing server 151 is valid. This flow is started when the access token refresh module 1051 of the service providing server 151 receives the access token validity confirmation request from the access token refresh request module 1032 of the intermediary server 131.

In step S1341, the access token refresh module 1051 receives an access token validity confirmation request from the access token refresh request module 1032 of the intermediary server 131. The access token validity confirmation request includes the access token.

In step S1342, the access token refresh module 1051 refers to the issued access token management table shown in Table 5. Then, the access token refresh module 1051 confirms whether the access token received in step S1341 is correct and whether it is within the expiration date.

Table 5 is an example of the issued access token management table. Table 5 shows that the expiration date of the access token “AT1” associated with the user ID “Ken” and the client ID “client_aa” is “2020.03.10”. Similarly, it indicates that the expiration date of the access token "AT2" associated with the user ID "Ken" and the client ID "client_bb" is "2020.08.10". It also indicates that the expiration date of the access token "AT3" associated with the user ID "Tom" and the client ID "client_cc" is "2020.09.10".

In step S1343, the access token refresh module 1051 transmits the confirmation result of step S1342 to the access token refresh request module 1032 of the intermediary server 131, and the flow ends.

FIG. 20B is a flow in which the service providing server 151 refreshes the access token. This flow is started when the access token refresh module 1051 of the service providing server 151 receives the access token refresh request. Here, the access token refresh request is transmitted from the access token refresh request module 1032 of the intermediary server 131.

In step S1361, the access token refresh module 1051 receives an access token refresh request from the access token refresh request module 1032 of the intermediary server 131. This access token refresh request includes a refresh token, a client ID, and a secret.

In step S1362, the access token refresh module 1051 refers to the issued refresh token management table shown in Table 6. Then, the access token refresh module 1051 determines whether the refresh token included in the access token refresh request received in step S1361 is valid. Further, the access token refresh module 1051 refers to the issued refresh token management table. Then, the access token refresh module 1051 determines whether the client ID included in the access token refresh request received in step S1361 and the refresh token are stored in association with each other.

Table 6 is an example of the issued refresh token management table. In Table 6, the refresh token "RT1" has an expiration date of "2021.03.10" and represents that the access token "AT1" associated with the client ID "client_aa" can be refreshed. Similarly, the refresh token "RT2" has an expiration date of "2021.08.10" and indicates that the access token "AT2" associated with the client ID "client_bb" can be refreshed. Further, the refresh token "RT3" has an expiration date of "2021.09.10", and indicates that the access token "AT3" associated with the client ID "client_cc" can be refreshed.

In step S1363, the access token refresh module 1051 refers to the client management table shown in Table 7. Then, the access token refresh module 1051 confirms whether the client ID and the secret included in the access token refresh request received in step S1361 are correct.

Table 7 is an example of a client management table. In Table 7, it is shown that the secret "secret001" is associated and stored in the client of the client ID "clinent_aa". Similarly, the secret "secret002" is associated and stored in the client of the client ID "clinent_bb". Further, the secret "secret003" is associated and stored in the client of "client_cc".

In step S1364, the access token refresh module 1051 determines whether the access token can be refreshed from the determination result of step S1362 and the confirmation result of step S1363. If the access token can be refreshed, the process proceeds to step S1365. On the other hand, if the access token cannot be refreshed, the process proceeds to step S1368.

In step S1365, the access token refresh module 1051 refreshes the access token and the refresh token. At the time of refreshing, the access token refresh module 1051 uses the refresh token, the client ID, and the secret received in step S1361.

In step S1366, the access token refresh module 1051 invalidates the access token and the refresh token before refreshing. For example, when a refresh is performed using RT1 and a new access token "AT10" and a refresh token "RT10" are issued, AT1 associated with RT1 is specified from Table 6. Further, AT1 in Table 5 and RT1 in Table 6 are invalidated, and new information on AT10 and RT10 is added to each table.

In step S1637, the access token refresh module 1051 transmits the refreshed access token and the refresh token. Here, the refreshed access token and the refresh token are transmitted to the access token refresh request module 1032 of the intermediary server 131. This ends the flow.

In step S1368, the access token refresh module 1051 sends a refresh error notification to the access token refresh request module 1032 of the intermediary server 131, and the flow ends.

According to the second embodiment, if the access token has expired before the user U2 operates the shared target resource, the latest authorization information is updated, so that the shared target resource can be accessed. ..

[Third Embodiment]
Hereinafter, the third embodiment of the present invention will be described with reference to the drawings. The parts common to the above-described embodiment will be omitted, and only the differences will be described below. When the access token is refreshed by the intermediary server 131, the old access token and refresh token possessed by the multifunction device 111 are invalidated. Therefore, the service providing server 151 cannot be accessed from the multifunction device 111. This embodiment has been made in view of this problem.

FIG. 21 is a diagram showing a module configuration according to the third embodiment, and shows the module configuration of the multifunction device 111. The multifunction device 111 of this embodiment has an access token update module 1401.

When updating the authorization information of the multifunction device 111, the access token refresh request module 1032 of the intermediary server 131 performs the access token refresh process. The access token refresh process is performed in response to a request from the access token update module 1401 of the multifunction device 111.

FIG. 22 is a device access token refresh flow according to the third embodiment. FIG. 22A is a second flow in which the multifunction device 111 receives the upload folder list. This flow is started when the multifunction device 111 accepts a service use operation by the user. In the description of this flow, only the difference from FIG. 6A will be described.

In step S1501, the access token update module 1401 transmits a device access token update request to the access token refresh request module 1032 of the intermediary server 131. This device access token update request includes an access token associated with the user identifier of the user U1 who operates the multifunction device 111, which is acquired by referring to the access token management table.

In step S1502, the access token update module 1401 receives the latest access token and refresh token. The latest access token and refresh token are transmitted as a response from the access token refresh request module 1032 of the mediation server 131.

In step S1503, the access token update module 1401 overwrites the permission information among the information stored in the access token management table. That is, the access token update module 1401 updates the access token and the refresh token associated with the user identifier of the user U1 who operates the multifunction device 111. When the update is completed, the process proceeds to step S501 and the process is continued.

FIG. 22B is a flow in which the intermediary server 131 updates the access token. This flow is started when the access token refresh request module 1032 of the intermediary server 131 receives the device access token update request from the access token update module 1401 of the multifunction device 111.

In step S1521, the access token refresh request module 1032 receives a device access token update request from the access token update module 1401 of the multifunction device 111. This device access token update request includes an access token.

In step S1522, the access token refresh request module 1032 transmits an access token update request to the access token refresh request module 1032 of the intermediary server 131. This access token update request includes the access token included in the device access token update request received in step S1521. When the update of the access token is completed, the process proceeds to step S1523 and the process is continued. In this way, the access token refresh request module 1032 functions as an authorization information transmission unit that transmits authorization information to the device.

In step S1523, the access token refresh request module 1032 refers to the access token management table and acquires the latest access token and refresh token associated with the user identifier of the user U1.

In step S1524, the access token refresh request module 1032 transmits the latest access token and the refresh token to the access token update module 1401 of the multifunction device 111. The latest access token and refresh token were acquired in step S1523. This ends the flow.

According to the present embodiment, even after the access token is refreshed by the intermediary server 131, it is possible to access the shared target resource from the multifunction device 111. In the present embodiment, the latest authorization information is transmitted to the multifunction device 111, but the present invention is not limited to this, and the latest authorization information may be transmitted to other devices.

Although the present invention has been described in detail based on the preferred embodiments thereof, the present invention is not limited to these specific embodiments, and various embodiments within the range not deviating from the gist of the present invention are also included in the present invention. Will be. In addition, some of the above-described embodiments may be combined as appropriate.

In the above-described embodiment, the shared folder has been illustrated as an example of the service to be used, but the present invention is not limited to this, and other services may be used.

(Other embodiments)
The present invention supplies a program that realizes one or more functions of the above-described embodiment to a system or device via a network or storage medium, and one or more processors in the computer of the system or device reads and executes the program. It can also be realized by the processing to be performed. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.

111 ... Multifunction device 131 ... Mediation server 151 ... Service provision server 171 ... User terminal 332 ... Shared information management module 333 ... Shared folder access module

Claims (7)

It is a server device that shares the usage target corresponding to the client information with a plurality of devices based on the authorization information corresponding to the specific client information and the usage identification information for using the usage target of the service. hand,
A password receiver that receives the first password set by the first device to share the usage target, and
A password storage unit that stores the first password in association with the authorization information and the first usage identification information,
An access request receiving unit that receives an access request transmitted from the second device to the usage target and includes the second usage identification information and the second password.
It has an access permission unit that determines whether or not to allow access to the access request.
The access permission unit is a server device that permits the access request when the first usage identification information and the first password match the second usage identification information and the second password. The server device further
A client information storage unit that stores the client information of the first device,
It has an authorization information update unit that updates the authorization information that is managed in association with the first use identification information.
The server device according to claim 1, wherein the authorization information updating unit updates the authorization information with the latest authorization information when the authorization information has expired. The server device further
It has an authorization information transmission unit that transmits the authorization information to the plurality of devices.
The server device according to claim 2, wherein the authorization information transmitting unit transmits the latest authorization information when the expiration date of the authorization information has expired. The server device according to any one of claims 1 to 3, wherein the access permission unit requests the setting of the first password when the first password is not set. Based on a plurality of devices, authorization information corresponding to specific client information, and usage identification information for using the usage target of the service, the usage target corresponding to the client information is applied to the plurality of devices. It is a system that has a server device to be shared.
The server device is
A password receiver that receives the first password set by the first device to share the usage target, and
A password storage unit that stores the first password in association with the authorization information and the first usage identification information,
An access request receiving unit that receives an access request transmitted from the second device to the usage target and includes the second usage identification information and the second password.
It has an access permission unit that determines whether or not to allow access to the access request.
The access permission unit is a system characterized in that when the first usage identification information and the first password match the second usage identification information and the second password, the access request is permitted. Control of a server device that shares the usage target corresponding to the client information with a plurality of devices based on the authorization information corresponding to the specific client information and the usage identification information for using the usage target of the service. It ’s a method,
The process of receiving the first password set by the first device to share the usage target, and
The process of storing the first password in association with the authorization information and the first usage identification information,
The process of receiving the access request transmitted from the second device to the usage target and including the second usage identification information and the second password, and the process of receiving the access request.
It has a process of determining whether or not to allow access to the access request.
The access permission unit is a control method comprising permitting the access request when the first usage identification information and the first password match the second usage identification information and the second password. A program comprising causing a computer to execute the control method according to claim 6.

Images