Server and computer program

Abstract

To mitigate a burden of a manager of a device in acquiring service use information for using a service by a user in the service using the device.SOLUTION: A server records device identification information identifying a specific device and manager identification information identifying a manager of the specific device by associating with each other in a memory, and records approval information received from a manager terminal device by associating with the device identification information in the memory. The server receives a use request from a user terminal device, determines whether or not the use request is approved using the approval information according to the use request, and transmits service use information used for a user to use a service, where the service use information is associated with the specific device, to the user terminal device when the use request is approved.SELECTED DRAWING: Figure 7

Description

Technical Field

[0001] This specification relates to a device that transmits service usage information used to utilize a service using a specific device, and a computer program.

Background Art

[0002] The printing server group disclosed in Patent Document 1 provides a printing service to users of a personal computer (also called a PC). For example, the printing server group receives a print instruction from a PC and transmits a print job for printing data on the network to a registered printer. As a result, the PC can cause the printer to print data on the network without a driver. The registered printer can be shared by multiple users, and the sharing settings of the users can only be performed by the registered administrator.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the above technology, the sharing settings for sharing a printer among multiple users are performed according to the operations of the administrator, so the burden on the administrator may increase.

[0005] This specification discloses a technology that can reduce the burden on the administrator of a device when a user acquires service usage information for using a service in a service using a device.

Means for Solving the Problems

[0006] The technologies disclosed herein can be implemented in the following applications:

[0007] [Application Example 1] A server comprising a first recording unit that records device identification information identifying a specific device and administrator identification information identifying the administrator of the specific device in association with each other in memory, and an administrator terminal device used by the administrator. Approval information A server comprising: a first receiving unit that receives information; a second recording unit that records the received approval information in memory in association with the device identification information; a second receiving unit that receives a usage request from a user terminal device used by a user, wherein the usage request is the first request by the user to use a service using the specific device; a determination unit that, in response to the usage request, determines whether or not to approve the usage request using the approval information; and a transmission unit that, if the usage request is approved, transmits the service usage information used by the user to use the service, which is associated with the specific device, to the user terminal device.

[0008] According to the above configuration, approval information received from the administrator terminal device and specific information received from the user terminal device are used to determine whether or not to approve the usage request. If the usage request is approved, service usage information associated with the specific device is sent to the user terminal device. As a result, the administrator does not need to perform approval processing each time a usage request is made, as they can send the approval information from the administrator terminal device to the server in advance. Therefore, in services that use devices, the burden on the device administrator can be reduced when obtaining service usage information that users use to access the service.

[0009] Furthermore, the technologies disclosed herein can be implemented in various forms, for example, as servers, terminal devices, processing methods, computer programs for realizing the functions of these devices and methods, recording media on which such computer programs are stored, and so on. [Brief explanation of the drawing]

[0010] [Figure 1] A block diagram showing the configuration of System 1000. [Figure 2] A diagram showing an example of a table. [Figure 3] The first sequence diagram of the startup process that is executed when no administrator is present. [Figure 4] A second sequence diagram of the startup process that is executed when no administrator is present. [Figure 5] A diagram showing an example of a screen displayed on a terminal device. [Figure 6] The first sequence diagram of the startup process that is executed when an administrator is present. [Figure 7] A second sequence diagram of the startup process that is executed when an administrator is present. [Figure 8] A third sequence diagram of the startup process that is executed when an administrator is present. [Figure 9] The fourth sequence diagram of the startup process, which is executed when an administrator is present. [Figure 10] Flowchart of the approval decision process. [Figure 11] A sequence diagram illustrating the printing service. [Figure 12] Diagram illustrating the second embodiment. [Figure 13] Diagram illustrating the third embodiment. [Figure 14] A diagram illustrating the authentication process. [Modes for carrying out the invention]

[0011] A. First Example A-1. Configuration of System 1000 FIG. 1 is a block diagram showing the configuration of system 1000. System 1000 includes printer 100, terminal devices 200A and 200B owned by the user of printer 100, device management server 300, account management server 400, and WEB server 500. Note that authentication server 600 is a configuration provided in the third embodiment and is not provided in the first and second embodiments. For this reason, authentication server 600 will be described in the third embodiment.

[0012] As a controller of printer 100, printer 100 includes CPU 110, volatile storage device 120 such as DRAM, and non-volatile storage device 130 such as a hard disk or flash memory. Printer 100 also includes display unit 140 such as a liquid crystal display for displaying an image, operation unit 150 such as buttons or a touch panel for acquiring operations by the user, printing mechanism 170, and communication interface (IF) 180.

[0013] Communication IF 180 is an interface for connecting to the Internet IT, for example, a wired interface compliant with Ethernet (registered trademark) or a wireless interface compliant with the Wi-Fi standard.

[0014] CPU 110 is an arithmetic unit (processor) that performs data processing. Volatile storage device 120 provides a buffer area for temporarily storing various intermediate data generated when CPU 110 performs processing. In non-volatile storage device 130, computer program PG1 for controlling printer 100 and information database IB in which various information such as device information described later is recorded are stored.

[0015] In this embodiment, computer program PG1 is provided by being pre-stored in non-volatile storage device 130 at the time of manufacturing printer 100. Instead of this, computer program PG1 can be provided in a form downloaded from a server connected via the Internet IT, or in a form recorded on a CD-ROM or the like.

[0016] The CPU 110 controls the printer 100 by executing the computer program PG1. For example, as will be described later, the CPU 110 works in cooperation with the device management server 300 to provide printing services to users. Specifically, when the CPU 110 receives a print job from the device management server 300, it controls the printing mechanism 170 according to the print job and causes the printing mechanism 170 to print the image. Also, as will be described later, the CPU 110 sends device information such as the device ID to the requesting terminal devices 200A and 200B in response to requests from those terminal devices.

[0017] The printing mechanism 170 performs printing according to the control of the CPU 110. The printing mechanism 170 in this embodiment is an inkjet printing mechanism that prints an image onto a recording medium using multiple types of ink (for example, four types of ink: cyan, magenta, yellow, and black) as colorants. Alternatively, the printing mechanism 170 may be an electrophotographic printing mechanism that prints an image onto a recording medium using toner as a colorant.

[0018] Terminal devices 200A and 200B are computers, such as smartphones. In variations, terminal devices 200A and 200B may be personal computers or tablet computers.

[0019] The terminal device 200A includes a CPU 210 as a controller, a volatile storage device 220 such as DRAM, and a non-volatile storage device 230 such as a hard disk or flash memory. The terminal device 200A also includes a display unit 240 such as a liquid crystal display for displaying images, an operation unit 250 such as buttons or a touch panel for acquiring user input, and a communication interface 280. The communication interface is a wireless communication interface compliant with, for example, the Wi-Fi standard or a mobile communication standard (for example, the LTE standard).

[0020] The volatile storage device 220 provides a buffer area for temporarily storing various intermediate data generated when the CPU 210 performs processing. The non-volatile storage device 230 stores the application program AP.

[0021] The application program AP enables the CPU 210 of the terminal device 200A to perform various processes related to the printing service, such as sending service usage requests to the account management server 400 and sending print requests to the device management server 300, as described later. For example, the application program AP is provided by a printing service provider (for example, a company that manufactures and sells printers 100). The application program AP is provided, for example, by being downloaded from a server connected via the Internet IT. Alternatively, the application program AP may be provided by being pre-installed on the terminal device 200A.

[0022] Terminal device 200B has the same configuration 210-280 (not shown) as terminal device 200A. In Figure 1, the diagram of configuration 210-280 is omitted, and only the application program AP stored in the non-volatile memory device 230 is shown. Hereinafter, the functions realized by the CPU 210 of terminal devices 200A and 200B by executing the application program AP will also be referred to as "terminal applications".

[0023] The device management server 300, account management server 400, and web server 500 are, for example, computers operated by a provider of printing services, such as cloud servers. These servers work together to perform the processing related to the printing service described later.

[0024] The device management server 300 includes a CPU 310 as a controller, a volatile storage device 320 such as DRAM, a non-volatile storage device 330 such as a hard disk or flash memory, and a communication interface (IF) 380. The communication IF 380 is, for example, a wired interface compliant with Ethernet®.

[0025] The CPU 310 is a processing unit (processor) that performs data processing. The volatile storage device 320 provides a buffer area for temporarily storing various intermediate data generated when the CPU 310 performs processing. The non-volatile storage device 330 stores the computer program PGa and the device management table TBa, which will be described later.

[0026] The account management server 400, like the device management server 300, includes a CPU 410 as a controller, a volatile storage device 420, and a communication interface 480. The volatile storage device 420 provides a buffer area for temporarily storing various intermediate data generated when the CPU 410 performs processing. The non-volatile storage device 430 stores the computer program PGb and the account management table TBb, which will be described later.

[0027] The web server 500, like the device management server 300, includes a CPU (not shown), volatile and non-volatile storage devices, and a communication interface. The non-volatile storage device of the web server 500 stores the computer program PGc.

[0028] The computer programs PGa, PGb, and PGc for these servers are provided, for example, by being uploaded by the service provider operating the printing service. The CPUs of servers 300, 400, and 500 execute processing related to the printing service by running the computer programs PGa, PGb, and PGc, respectively. For example, the device management server 300 mainly manages information related to managed printers such as printer 100, and generates and sends print jobs. The account management server 400 mainly manages information related to users (such as account information and email addresses, which will be described later). The web server 500 mainly handles communication with terminal applications running on terminal devices 200A and 200B.

[0029] These servers 300, 400, and 500 are connected to each other via the Internet of Things (IT). It can also be said that servers 300, 400, and 500 together constitute a single server for providing printing services.

[0030] These servers 300, 400, and 500 can communicate with printer 100 and terminal devices 200A and 200B via the Internet IT. Printer 100 and terminal devices 200A and 200B can communicate with each other via the Internet IT or a local area network (not shown).

[0031] Although Figure 1 only shows one printer 100 and two terminal devices 200A and 200B, the device management server 300 provides printing services to numerous users using multiple printers. The following describes various processes for printing services to one printer 100 and its user terminal devices 200A and 200B. These processes are executed independently for each managed printer and its user terminal device.

[0032] Figure 2 shows an example of a table. As shown in Figure 2(A), the device management table TBa includes the device table DT and the device token table TT.

[0033] The device table DT is a table that records device information. The device information includes the device ID and printer information such as the name and model number of the printer to which the device ID is assigned. The device table DT records the device ID and printer information of the managed printer (for example, printer 100 in Figure 1) in association with each other.

[0034] The device token table TT is a table that records device tokens. A device token is authentication information associated with the printer to be used. Device tokens are used as authentication information when terminal devices 200A and 200B use the print service, and are also used to specify the printer to be used. In this embodiment, there are two types of users of the print service: administrators and general users. Two types of tokens are used for the device token: an administrator token assigned to the administrator and a general user token assigned to the general user.

[0035] The device token table TT records device tokens assigned to users, associated with attribute information that indicates the attributes of the device token. As shown in Figure 2(A), the attribute information includes the type of device token, the device ID of the printer associated with the device token, the date and time the device token was created, and the status of the device token. The type of device token is either for administrators or for general users, as described above. The status of a device token is either authenticated or unauthenticated. An authenticated device token is a valid token that can be used when using the print service. An unauthenticated device token is an invalid token that cannot be used until it is authenticated.

[0036] As shown in Figure 2(B), the account management table TBb includes the account table AT, the administrator table MT, and the email address table MAT.

[0037] The account table AT is a table that records account information for each administrator's account. In this embodiment, as will be described later, administrators need to register an account in order to use the printing service, but general users can use the printing service without registering an account. For this reason, in this embodiment, the only accounts registered in the account table AT are the accounts of the registrants. Each account information includes an account ID, password, username, and notification token, as shown in Figure 2(B). The notification token is a token used by the server 300 to send push notifications to the terminal device of the account owner (i.e., the administrator). The notification token is authentication information assigned to a combination of terminal device and terminal application. By sending push notifications using the notification token, push notifications can be sent to the terminal application of the terminal device to which the notification token is assigned. Push notifications are sent using a well-known push notification service such as FCM (Firebase Cloud Messaging).

[0038] As shown in Figure 2(B), the administrator table MT records the administrator's account ID and the printer's device ID in association. This associates the administrator's account with the printer. An account associated with a specific printer is also called a corresponding account. The administrator table MT also records approval information, associated with the account ID and device ID. The approval information is used to determine whether or not to approve a service request from a general user. In the first embodiment, the approval information is the password determined by the administrator.

[0039] The email address table MAT temporarily records the user's email address during the initial setup process described later. As shown in Figure 2(B), the email address table MAT records the email address in association with the device ID.

[0040] A2. Processing to start using the printing service A-2-1. Handling the case where there is no administrator for printer 100. A user who wishes to receive printing services using printer 100 sends a service request to servers 300-500 that provide printing services using their own terminal device. Initially, there is no administrator for printer 100. The service request is the first request a user makes to use the printing service with printer 100.

[0041] First, we will explain the case where a user of terminal device 200A sends a service usage request using terminal device 200A in the absence of an administrator. Figures 3 and 4 are sequence diagrams of the service activation process that is executed when there is no administrator.

[0042] The user of terminal device 200A launches the terminal application on terminal device 200A. The user specifies printer 100 and inputs a command to start the print service into the terminal application. For example, the user enters the IP address of printer 100 on an input screen (not shown) and presses the start command button.

[0043] In S2, terminal device 200A sends a device information request to printer 100 in response to a start command. The device information request is sent, for example, with the entered IP address as the destination.

[0044] When printer 100 receives a device information request, in S4 it transmits device information to terminal device 200A as a response to the device information request. The transmitted device information includes the device ID of printer 100 and printer information (see Figure 2(A)).

[0045] Upon receiving device information, terminal device 200A sends a service request to the web server 500 via S6. The service request includes the received device information (device ID and printer information).

[0046] When the web server 500 receives a service request, it sends a device administrator verification request to the account management server 400 via S8. The device administrator verification request includes the received device information (device ID and printer information).

[0047] When the account management server 400 receives a device administrator verification request, it verifies the device administrator in S10. Specifically, the account management server 400 determines whether the device ID included in the device administrator verification request is recorded in the administrator table MT in association with the account ID. In this case, as mentioned above, the administrator of printer 100 is not registered, so the device ID included in the device administrator verification request is not recorded in the administrator table MT.

[0048] In response to the device administrator verification request, the account management server 400 sends a device administrator absence notification to the web server 500 in S12, indicating that the administrator of printer 100 is not registered.

[0049] When the web server 500 receives an administrator absence notification, it sends an account information acquisition request to the terminal device 200A in S14 as a response to the service usage request. When the terminal device 200A receives the account information acquisition request, it displays the account information input screen W1 on the display unit 240 of the terminal device 200A in S16. In this way, the account information input screen W1 is displayed in response to the account information acquisition request, so the account information acquisition request can also be said to be a request to display the account information input screen W1.

[0050] Figure 5 shows an example of a screen displayed on a terminal device. The account information input screen W1 in Figure 5(A) includes input fields BX1 to BX3 and a send button BT1. Input field BX1 is for entering the account ID. Input field BX2 is for entering the password. Input field BX3 is for entering the user's name.

[0051] When a user enters account information (in this embodiment, account ID, password, and name) into the account information input screen W1 and presses the send button BT1, the terminal device 200A retrieves the account information via the account information input screen W1 in S18.

[0052] When terminal device 200A obtains account information, it sends an account creation request to web server 500 in S19. The account creation request includes the account information obtained in S18, a notification token, and device information received in S4. The notification token is obtained in advance from a server that provides a well-known push notification service, such as FCM (Firebase Cloud Messaging), by requesting it from the terminal device 200A.

[0053] When the web server 500 receives an account creation request, it sends the account creation request to the account management server 400 via S20.

[0054] When the account management server 400 receives an account creation request, in S22 it creates an account based on the account information included in the account creation request, i.e., an account for the user of terminal device 200A. Specifically, the account management server 400 records the account information (account ID, password, name) in the account table AT (Figure 2(B)) in association with the notification token.

[0055] In S24, the account management server 400 registers the user account of the created terminal device 200A in association with the printer 100. Specifically, the account management server 400 records the account ID of the user's account in the administrator table MT (Figure 2(B)) in association with the device ID included in the received device information. As a result, the user of terminal device 200A is registered as the administrator of printer 100. Hereafter, the user of terminal device 200A will also be referred to as the administrator of printer 100, and the user account of terminal device 200A will also be referred to as the associated account for printer 100.

[0056] When the account management server 400 registers a corresponding account, it sends a token issuance request to the device management server 300 via S26. The token issuance request is a request for the issuance of the device token described above. The token issuance request includes device information.

[0057] When the device management server 300 receives a token issuance request, it registers the printer 100 as a managed printer in S27 of Figure 4. Specifically, the device management server 300 records the device information (device ID and printer information) in the device table DT (Figure 2(A)).

[0058] In S28, the device management server 300 issues an authenticated device token. Specifically, the device management server 300 generates a device token and records it in the device token table TT (Figure 2(A)). The device management server 300 further records in the device token table TT the type information indicating that it is an administrator, the device ID included in the device information, the generation date and time, and the status information indicating that it is authenticated, associating them with the device token.

[0059] In S30, the device management server 300 sends the issued authenticated device token to the account management server 400 in response to the token issuance request.

[0060] When the account management server 400 receives an authenticated device token, it sends an account creation completion notification to the terminal device 200A in S32. The account creation completion notification is sent as a push notification using the notification token of terminal device 200A recorded in the account table AT. The account creation completion notification includes the authenticated device token.

[0061] When terminal device 200A receives an account creation completion notification, in S34 it stores the authenticated device token included in the account creation completion notification in the non-volatile storage device 230.

[0062] In S36, the terminal device 200A displays the approval information input screen W2 on the display unit 240. The approval information input screen W2 is a screen for the administrator to input approval information to be recorded in the administrator table MT (Figure 2(B)) described above. The approval information input screen W2 in Figure 5(B) includes a message MS1 prompting the input of approval information, a password input field BX4 as approval information, and a setting button BT2.

[0063] When a user (administrator) of terminal device 200A enters the password to be set as approval information into input field BX4 on the approval information input screen W2 and presses the setting button BT2, terminal device 200A obtains the approval information (password in this embodiment) via the approval information input screen W2 in S35.

[0064] When terminal device 200A obtains authorization information (a password in this embodiment), it sends the authorization information to the web server 500 in S37. When web server 500 receives the authorization information, it sends the authorization information to account management server 400 in S38.

[0065] When the account management server 400 receives approval information, it saves the approval information to the non-volatile storage device 430 in S39. Specifically, the account management server 400 records the approval information in the administrator table MT (Figure 2(B)) stored in the non-volatile storage device 430, associating it with the administrator's account ID and device ID. After S39, the start-up process is completed.

[0066] As described above, the user account of terminal device 200A is registered with the account management server 400 as the corresponding account for printer 100. In other words, the user of terminal device 200A is registered as the administrator of printer 100. Furthermore, printer 100 is registered with the device management server 300 as a managed printer. In addition, terminal device 200A obtains an authenticated device token. As a result, as will be described later, the user of terminal device 200A can use the printing service using terminal device 200A (terminal application). Also, a password as authorization information is recorded in the account management server 400, associated with the account ID of the user (administrator) of terminal device 200A and the device ID of printer 100. The user of terminal device 200A, as an administrator, provides the password to the person who is authorized to use the printing service using printer 100, in this embodiment, the user of terminal device 200B.

[0067] A-2-2. Procedure when there is an administrator for printer 100 Next, we will explain the case where the user activation process is performed when an administrator is present. That is, after the user activation process shown in Figures 3 and 4 above has been performed and the user of terminal device 200A has been registered as the administrator of printer 100, we will explain the case where the user of terminal device 200B makes a usage request using terminal device 200B. Figures 6 to 9 are sequence diagrams of the user activation process that is performed when an administrator is present.

[0068] After being informed of the password by the user of terminal device 200A, the user of terminal device 200B starts the terminal application on terminal device 200B in the same way as the user of terminal device 200A described above. The user specifies printer 100 and enters a command to start the print service into the terminal application.

[0069] Steps S52, S54, S56, and S58 in Figure 6 are the same processes as steps S2, S4, S6, and S8 in Figure 3. Specifically, in step S52, terminal device 200B sends a device information request to printer 100 in response to a start command. Upon receiving the device information request, printer 100 sends the device information to terminal device 200B in step S54. Upon receiving the device information, terminal device 200A sends a service usage request to web server 500 in step S56. Upon receiving the service usage request, web server 500 sends a device administrator verification request to account management server 400 in step S58.

[0070] When the account management server 400 receives a device administrator verification request, it verifies the device administrator in S60. Specifically, the account management server 400 determines whether the device ID included in the device administrator verification request is recorded in the administrator table MT in association with the account ID. In this case, as described above, the user of terminal device 200A is already registered as the administrator of printer 100. That is, since the corresponding account associated with printer 100 is already registered, the device ID included in the device administrator verification request (the device ID of printer 100) is recorded in the administrator table MT in association with the account ID.

[0071] In response to the device administrator verification request, the account management server 400 sends a device administrator existence notification to the web server 500 in S62, indicating that the administrator of printer 100 is registered.

[0072] When the web server 500 receives a notification of administrator presence, it sends a service application request to the terminal device 200B in S64 as a response to the service usage request. This service application request is different from the account information acquisition request (S14 in Figure 3) described above. Thus, the requests sent from the web server 500 to the terminal device differ depending on whether or not the administrator of the printer 100 is registered.

[0073] When terminal device 200B receives a usage application request, it displays the usage application screen W3 on the display unit 240 of terminal device 200B in S66. In this way, since the usage application screen W3 is displayed in response to the usage application request, the usage application request can also be said to be a request to display the usage application screen W3.

[0074] The application screen W3 in Figure 5(C) includes input fields BX5 and BX6 for entering application-related information, and a send button BT1. Input field BX5 is for entering an email address. Input field BX6 is for entering a password. In this way, if the administrator of printer 100 is registered, other users (general users) do not need to enter account information such as device ID and name, but only need to enter their own email address and the password provided by the administrator.

[0075] When a user enters their email address and password on the application screen W3 and presses the send button BT1, terminal device 200B, in S68, obtains application-related information (email address and password in this embodiment) via the application screen W3.

[0076] When terminal device 200B obtains application-related information, it sends the application to the web server 500 in S70. The application includes the application-related information obtained in S68 and the device information received in S54.

[0077] When the web server 500 receives a usage request, it sends the usage request to the account management server 400 via S72.

[0078] When the account management server 400 receives an application, in S73 it records the email address included in the application in the email address table MAT (Figure 2(B)). The device ID included in the device information obtained in S58 is associated with the email address.

[0079] In S74, the account management server 400 retrieves approval information sent by already registered administrators. Specifically, the account management server 400 refers to the administrator table MT and retrieves approval information associated with the device ID included in the usage application.

[0080] When the account management server 400 obtains the approval information, it executes the approval determination process at S76 in Figure 7. The approval determination process uses specific information (a password in this embodiment) included in the application-related information and the approval information to determine whether or not to approve the service usage request from a general user.

[0081] Figure 10 is a flowchart of the approval decision process. In S210, the account management server 400 determines whether the password included in the application matches the password obtained in S74, that is, the password set by the administrator.

[0082] If the password included in the application matches the password set by the administrator (S210:YES), the account management server 400 decides in S230 to approve the service usage request. If the password included in the application does not match the password set by the administrator (S210:NO), the account management server 400 decides in S220 not to approve the service usage request. Once a decision has been made on whether or not to approve the service usage request, the approval process is terminated.

[0083] If the approval process determines that the service usage request should be approved (S78: YES in Figure 7), the account management server 400 sends a token acquisition URL request to the device management server 300 in S80. The token acquisition URL is the URL (Uniform Resource Locator) used by the applicant to obtain a device token. The token acquisition URL request includes the device information received in S58.

[0084] When the device management server 300 receives a request for a token acquisition URL, it issues an unauthenticated device token in S82. Specifically, the device management server 300 generates a device token and records it in the device token table TT (Figure 2(A)). The device management server 300 further records type information indicating that the user is a regular user, the device ID included in the device information, the generation date and time, and status information indicating that the user is unauthenticated, in association with the device token, and records these in the device token table TT.

[0085] In S84, the device management server 300 generates a URL indicating the location of the issued unauthenticated device token as the token acquisition URL. In S86, the device management server 300 sends the token acquisition URL to the account management server 400 as a response to the token acquisition URL request.

[0086] When the account management server 400 receives the token acquisition URL, it sends the token acquisition URL to the web server 500 via S88. At this time, along with the token acquisition URL, the email address included in the application (in this embodiment, the email address of the user of terminal device 200B) is sent to the web server 500.

[0087] When the web server 500 receives the token acquisition URL and email address, it sends the token acquisition URL to the email address in S89. That is, an email containing the token acquisition URL is sent via a mail server (not shown). This sends the token acquisition URL to the terminal device 200B.

[0088] When terminal device 200B receives a token acquisition URL via email, it displays the token acquisition URL on display unit 240 in response to the user's input of an instruction to view the email via S90. Figure 5(D) shows an example of the display screen W4 for the token acquisition URL. Display screen W4 in Figure 5(D) is a screen that displays an email containing the token acquisition URL, and includes message MS2 and a link LK indicating the token acquisition URL. Message MS2 is a message that notifies the user that the service usage request for printer 100 has been approved and prompts the user to access the token acquisition URL to obtain a device token.

[0089] For example, the user inputs a token acquisition instruction to the terminal device 200B by tapping the link LK on the display screen W4. As a result, the terminal device 200B receives the token acquisition instruction in S92.

[0090] When terminal device 200B receives a token acquisition instruction, it sends a token acquisition request to the device management server 300 at S94 in Figure 8. In this embodiment, the token acquisition request is an HTTP (Hypertext Transfer Protocol) request specifying the token acquisition URL associated with the link LK.

[0091] When the device management server 300 receives a token acquisition request, it changes the status of the device token from unauthorized to authenticated in S96. Specifically, the device management server 300 changes the status of the device token associated with the token acquisition URL in the device token table TT (Figure 2(A)) from unauthorized to authorized.

[0092] In S98, the device management server 300 sends an authenticated device token associated with the token acquisition URL to the terminal device 200B as a response to the token acquisition request. For example, the device management server 300 sends the authenticated device token as an HTTP response to an HTTP request that is a token acquisition request.

[0093] When terminal device 200B receives an authenticated device token, it stores the authenticated device token in the non-volatile storage device 230 in S99. This completes the start-up process.

[0094] Through the activation process described above, terminal device 200B obtains an authenticated device token without registering a user account for terminal device 200B. As a result, as will be described later, the user of terminal device 200B becomes able to use the printing service using terminal device 200B (terminal application).

[0095] If the approval process determines that the service usage request should not be approved (S78: NO in Figure 7), the account management server 400 sends an unavailability notification to the web server 500 at S88B in Figure 9. At this time, along with the unavailability notification, the email address included in the usage application (in this embodiment, the email address of the user of terminal device 200B) is sent to the web server 500.

[0096] When the web server 500 receives an unavailability notification and an email address, it sends an unavailability notification to the email address via S89B. That is, an email containing the unavailability notification is sent via a mail server (not shown). This sends the unavailability notification to the terminal device 200B.

[0097] When terminal device 200B receives an unavailability notification via email, it displays the unavailability notification on the display unit 240 in response to the user's input of an instruction to view the email via S90B. Although the display screen for the unavailability notification is not shown in the illustration, for example, the display screen includes a message notifying the user that the application for use has not been approved and that the print service cannot be used. In this case, terminal device 200B cannot obtain an authenticated device token. Therefore, the user of terminal device 200B cannot use the print service.

[0098] A3. Printing Services This section describes the printing service provided to terminal devices 200A and 200B after they have acquired a device token. Figure 11 is a sequence diagram illustrating the printing service.

[0099] Both the user of terminal device 200A (administrator) who has obtained an administrator device token, and the user of terminal device 200B (general user) who has obtained a general user device token, can use the print service to print to printer 100. The following explanation uses the case of a user of terminal device 200B performing a print as an example, but the user of terminal device 200A can also print in the same way.

[0100] When a user of terminal device 200B launches a terminal application, terminal device 200B (terminal application) displays a print instruction input screen (not shown) on the display unit 240 of terminal device 200B in S102. The user can input a print instruction by specifying an image file that represents the image to be printed via the print instruction input screen. The image file is selected, for example, from files stored in the non-volatile storage device 230.

[0101] In response to user input, terminal device 200B obtains a print command, including the specification of an image file, in S104. Upon obtaining the print command, terminal device 200B sends a print request to the web server 500 in S106. The print request includes the specified image file and the device token obtained during the initial setup process described above.

[0102] When the web server 500 receives a print request, it sends the print request to the device management server 300 in S108.

[0103] When the device management server 300 receives a print request, it executes a token verification process in S110. In the token verification process, the device management server 300 checks whether the device token included in the print request is recorded in the device token table TT (Figure 2(A)). If the device token is recorded, the device management server 300 identifies the printer to which the print job will be sent (printer 100 in this embodiment) by obtaining the device ID associated with the device token in the device token table TT. Although not shown in the diagram, if the device token included in the print request is not recorded in the device token table TT, an error notification is sent from the device management server 300 to the terminal device via the web server 500, and the process is interrupted.

[0104] In S112, the device management server 300 generates a print job using the image file included in the print request. Specifically, rasterization, color conversion, and halftone processing are performed on the image data included in the image file to generate print data. A print job is then generated that includes this print data and print control data indicating print settings, etc.

[0105] In S114, the device management server 300 sends a print job to the printer 100. The print job is sent using a known method. For example, the device management server 300 has previously established a permanent connection with the printer 100 that follows XMPP (eXtensible Messaging and Presence Protocol), and uses this XMPP connection to send a print job notification to the printer 100. In response to the print job notification, the printer 100 sends a request to send the print job to the device management server 300, and the device management server 300 sends the print job in response to the request.

[0106] When printer 100 receives a print job, it executes printing based on the print job in S116. As a result, the image indicated by the image file specified by the user is printed by printer 100. By using this printing service, terminal device 200B can have printer 100 print an image without having to perform the process of generating a print job from an image file. For this reason, terminal device 200A can have printer 100 print an image even if a printer driver is not installed on terminal device 200A.

[0107] According to the embodiment described above, the account management server 400 associates the device ID, which is identification information for identifying the printer 100, with the account ID, which is identification information for identifying the administrator of the printer 100, and records them in the non-volatile storage device 430 (administrator table MT in Figure 2(B)) (S24 in Figure 3). The account management server 400 associates the approval information (a password set by the administrator in this embodiment) received from the terminal device 200A used by the administrator with the device ID and records it in the non-volatile storage device 430 (administrator table MT in Figure 2(B)) (S39 in Figure 4). The account management server 400 receives service usage requests from the terminal device 200B used by general users via the web server 500 (S56, S58 in Figure 6). The account management server 400 determines whether or not to approve the service usage request using the approval information in response to the service usage request (S76 in Figure 7, Figure 10). When the device management server 300 and account management server 400 approve a service usage request (YES in S78 of Figure 7), they send a device token, which is service usage information used by the user to access the print service, to the terminal device 200B (S88 in Figure 7, S98 in Figure 8). In this way, the approval information received from the administrator's terminal device 200A is used to determine whether or not to approve the service usage request, and if the service usage request is approved, a device token as service usage information is sent to the user terminal device. As a result, the administrator does not need to perform approval processing each time a service usage request is made, as they can send the approval information from their own terminal device 200A to the account management server 400 in advance. Therefore, in a service using the printer 100, the burden on the device administrator can be reduced when obtaining service usage information for general users (for example, the user of terminal device 200B) to access the service.

[0108] For example, it is preferable that users who should be able to use the printing service using printer 100 are those who are in line with the intentions of the printer 100's administrator, so it is undesirable for service usage requests to be approved unconditionally. On the other hand, if an approval request were sent to the administrator every time a user requests to use the service, and the administrator had to perform the approval process, the administrator's burden could become excessively large. According to this embodiment, the administrator only needs to send approval information (a password in this embodiment) in advance, thus reducing the administrator's burden.

[0109] Furthermore, according to this embodiment, the account management server 400 receives specific information (in this embodiment, the password included in the application-related information) from the terminal device 200B (S70, S72 in Figure 6). The account management server 400 uses the approval information and the specific information to determine whether or not to approve the service usage request. Specifically, the account management server 400 determines to approve the service usage request if the password as specific information matches the password as approval information (YES in S210 in Figure 10) (S230 in Figure 10). As a result, the account management server 400 can easily determine whether or not to approve the service usage request.

[0110] Furthermore, according to this embodiment, the approval information is a password notified to the user by the administrator. As a result, the administrator can appropriately approve service requests from users simply by notifying them of the password in advance, thereby reducing the administrator's burden. In addition, since those who do not know the password cannot have their service requests approved, the unauthorized use of the printing service can be deterred.

[0111] Furthermore, according to this embodiment, the account management server 400 records the device ID, account ID, and other information in association with each other in response to a service request from the administrator's terminal device 200A (S6 in Figure 3) (S24 in Figure 3). After the device ID and account ID are recorded, the account management server 400 receives a password as authorization information from the administrator's terminal device 200A (S37, S38 in Figure 4). As a result, after the administrator of the printer 100 is registered, the administrator only needs to send authorization information from the terminal device 200A to the web server 500, thus reducing the burden on the administrator.

[0112] Furthermore, according to this embodiment, the web server 500 displays a user application screen W3 for entering a password as specific information on the display unit 240 of the terminal device 200B (S64 in Figure 6). The web server 500 receives the specific information entered on the user application screen W3 from the terminal device 200B (S70 in Figure 6). General users can easily send specific information from the terminal device 200B to the web server 500 by entering a password as specific information on the user application screen W3.

[0113] As can be seen from the above explanation, the servers 300, 400, and 500 in this embodiment are examples of servers, terminal device 200A is an example of an administrator terminal device, and terminal device 200B is an example of a user terminal device. The password set by the administrator is an example of approval information, and the password entered by a general user on the application screen W3 is an example of specific information. The application screen W3 is an example of an input screen, and the device token is an example of service usage information.

[0114] B. Second Example In the first embodiment, a password is used as the authorization information and the identification information, but in the second embodiment, the domain name of the email address is used as the authorization information and the email address is used as the identification information. Figure 12 is an explanatory diagram of the second embodiment. Below, the parts of the processing in the second embodiment that differ from the first embodiment will be explained with reference to Figure 12.

[0115] In the second embodiment, the approval information input screen displayed on the display unit 240 of the terminal device 200A at S35 in Figure 4 differs from that of the first embodiment. Figure 12(B) shows the approval information input screen W2b of the second embodiment. The approval information input screen W2b in Figure 12(B) includes a message MS1b prompting the input of approval information (domain name in this embodiment), an input field BX4b for the domain name as approval information, and a setting button BT2. On the approval information input screen W2b, the administrator enters the domain name to be set as approval information into the input field BX4b and presses the setting button BT2. The entered domain name is sent as approval information from the account management server 400 to the account management server 400 via the web server 500 (S37, S39 in Figure 4), and recorded in the administrator table MT stored in the non-volatile storage device 430 of the account management server 400 (S39 in Figure 4, Figure 2(B)).

[0116] In the second embodiment, the application screen displayed on the display unit 240 of the terminal device 200B at S66 in Figure 6 differs from that of the first embodiment. Figure 12(C) shows the application screen W3b of the second embodiment. The application screen W3b in Figure 12(C) includes an input field BX5 for entering an email address as application-related information, and a send button BT1. Unlike the application screen W3 in Figure 5(B), the application screen W3b does not include a password input field. Thus, in the second embodiment, the only information that a general user needs to enter as application-related information is their own email address.

[0117] In the second embodiment, the content of the approval decision process in S76 of Figure 7 differs from the approval decision process in the first embodiment (Figure 10). Figure 12(A) is a flowchart of the approval decision process in the second embodiment. In the approval decision process of the second embodiment, S210B is executed instead of S210 in Figure 10. In S210B, the account management server 400 determines whether the domain name of the email address included in the application matches the domain name obtained as approval information in S74, that is, the domain name set by the administrator.

[0118] If the domain name of the email address included in the application matches the domain name set by the administrator (S210B:YES), the account management server 400 decides in S230 to approve the service usage request. If the domain name of the email address included in the application does not match the domain name set by the administrator (S210B:NO), the account management server 400 decides in S220 not to approve the service usage request. Once a decision has been made on whether or not to approve the service usage request, the approval process is terminated.

[0119] The configuration of the second embodiment, aside from the differences mentioned above, is the same as that of the first embodiment, so its explanation will be omitted.

[0120] According to the second embodiment described above, the account management server 400 determines to approve the service usage request when a part of the specific information (in this embodiment, the domain name which is part of the email address) matches the approval information (in this embodiment, the domain name) (YES in S210B of Figure 12(A)) (S230 in Figure 12(A)). As a result, the account management server 400 can easily determine whether or not to approve the service usage request.

[0121] Furthermore, according to this embodiment, the specific information is information owned by the user making the service request, specifically, personal information such as an email address. As a result, the burden on the device administrator can be further reduced. For example, in the first embodiment, a password is used as the specific information, so the administrator needs to notify users who should be allowed to use the printing service of the specific information, but this is not necessary in this embodiment.

[0122] Furthermore, in this embodiment, the specific information is an email address, and the approval information is the domain name of the email address. Since email addresses are widely used, general users can easily apply for use using their email addresses. Also, the domain names of email addresses belonging to a particular organization (for example, employees of a particular company) are often common. For example, an administrator may allow individuals belonging to that particular organization to use the printing service using printer 100, and may not allow individuals not belonging to that particular organization to use the printing service using printer 100. In such cases, the administrator can easily cause the account management server 400 to perform an appropriate approval judgment process by using the domain name used for the email address of an individual belonging to that particular organization as the approval information.

[0123] Furthermore, in this embodiment, the web server 500 and the account management server 400 use the aforementioned specific information (in this embodiment, an email address) to transmit a device token, which is service usage information. Specifically, by sending a token acquisition URL to the email address (S88, S89 in Figure 7), the terminal device 200B is made to access the token acquisition URL (S94 in Figure 8), and the device token is sent to the terminal device 200B as a response to this access (S98 in Figure 8). In this way, the specific information used in the approval judgment process is also used to transmit service usage information. Therefore, the amount of information that a general user must input into the application screen W2b as application-related information can be reduced.

[0124] According to the above configuration, specific information is also used to transmit service usage information, thus reducing the amount of information that users need to input.

[0125] C. Third Example The system 1000 of the third embodiment includes an authentication server 600, as shown in Figure 1. The authentication server 600 is, for example, a server that performs authentication processing for accounts used to access existing web services. Existing web service accounts are, for example, accounts for web services other than printing services (e.g., accounts for Google® or Apple®). In this case, the authentication server 600 is, for example, a server operated by a business operator that provides web services different from the printing services provided by servers 300 to 500. Alternatively, the authentication server 600 is, for example, a server that manages accounts of members of a specific organization (e.g., a company) to which administrators and general users belong, and performs authentication processing for those accounts. In this case, the authentication server 600 is, for example, an AD server that implements a function called Active Directory (abbreviated as AD) provided by Microsoft®.

[0126] In the third embodiment, the authorization information used is information for accessing the authentication server 600, specifically a URL (Uniform Resource Locator) indicating the location of the authentication server 600. Figure 13 is an explanatory diagram of the third embodiment. Below, the parts of the processing in the third embodiment that differ from those in the first and second embodiments will be explained with reference to Figure 13.

[0127] In the third embodiment, the approval information input screen displayed on the display unit 240 of the terminal device 200A at S35 in Figure 4 differs from that of the first embodiment. Figure 13(B) shows the approval information input screen W2c of the third embodiment. The approval information input screen W2c in Figure 13(B) includes a message MS1c prompting the input of approval information (in this embodiment, the URL of the authentication server 600), an input field BX4c for the URL as approval information, and a setting button BT2. On the approval information input screen W2c, the administrator enters the URL to be set as approval information into the input field BX4c and presses the setting button BT2. The entered URL is sent as approval information from the account management server 400 to the account management server 400 via the web server 500 (S37, S39 in Figure 4), and is recorded in the administrator table MT stored in the non-volatile storage device 430 of the account management server 400 (S39 in Figure 4, Figure 2(B)).

[0128] In the third embodiment, the application screen displayed on the display unit 240 of the terminal device 200B at S66 in Figure 6 is the same as the application screen W3b (Figure 12(C)) in the second embodiment, unlike in the first embodiment. That is, in the third embodiment, the only information that a general user needs to enter as application-related information is their own email address. However, this email address is used for sending the token acquisition URL (S88, S89 in Figure 7) and sending the unavailability notification (S88B, S89B in Figure 9), as in the first embodiment. Unlike in the second embodiment, this email address is not used for the approval decision process.

[0129] In the third embodiment, the content of the approval decision process at S76 in Figure 7 differs from the approval decision processes in the first and second embodiments (Figures 10 and 12(A)). Figure 13(A) is a flowchart of the approval decision process in the third embodiment. At S310, the account management server 400 sends an authentication request from the authentication server 600 to the terminal device 200B. Specifically, the account management server 400 sends a redirect instruction to the terminal device 200B, specifying the URL of the authentication server 600, which has been recorded as approval information, as the redirect destination. Upon receiving the redirect instruction, the terminal device 200B sends an authentication request specifying the said URL. As a result, an authentication request is sent from the terminal device 200B to the authentication server 600.

[0130] When the authentication server 600 receives an authentication request, it executes the authentication process. Figure 14 is an explanatory diagram of the authentication process. Figure 14(A) shows a flowchart of the authentication process. In S410, the authentication server 600 displays the authentication information input screen W5 on the display unit 240 of the terminal device 200B. Specifically, as a response to the authentication request, the authentication server 600 sends screen data showing the authentication information input screen W5 to the terminal device 200B.

[0131] Figure 14(B) shows an example of the authentication information input screen W5. The authentication information input screen W5 in Figure 14(B) includes a message MS3 prompting the user to enter authentication information, an input field BX7 for the authentication account ID, an input field BX8 for the password, and a login button BT3. This authentication information (account ID and password) is, for example, the authentication information that a user of terminal device 200B uses to access other web services. On the authentication information input screen W5, the user of terminal device 200B enters the authentication account ID in input field BX7, enters the password in input field BX8, and presses the login button BT3. As a result, terminal device 200B obtains this authentication information (account ID and password) and sends it to the authentication server 600. In S420, the authentication server 600 receives the authentication information from terminal device 200B. Since the communication of authentication information takes place between terminal device 200B and the authentication server 600, the authentication information is not sent to the account management server 400.

[0132] In S430, the authentication server 600 performs authentication based on the received authentication information. That is, it determines whether or not to authenticate the authentication request based on whether or not the received authentication information matches the authentication information managed by the authentication server 600. In S440, the authentication server 600 sends the authentication result to the account management server 400 and terminates the authentication process.

[0133] Once the authentication process by the authentication server 600 is complete, in S320 of Figure 13(A), the account management server 400 receives the authentication result from the authentication server 600. In S330, the account management server 400 determines, based on the received authentication result, whether or not the applicant (in this embodiment, the user of terminal device 200B) has been authenticated by the authentication server 600.

[0134] If the applicant is authenticated by the authentication server 600 (S330: YES), the account management server 400 decides in S350 to approve the service request. If the applicant is not authenticated by the authentication server 600 (S330: NO), the account management server 400 decides in S340 not to approve the service request. Once a decision is made on whether or not to approve the service request, the approval process is terminated.

[0135] Aside from the differences mentioned above, the configuration of the third embodiment is the same as that of the first embodiment, so its explanation will be omitted.

[0136] According to the third embodiment described above, the authorization information is access information (in this embodiment, a URL) that indicates a specific access destination (in this embodiment, the authentication server 600). The account management server 400 uses the URL, which is the access information, to access the authentication server 600, which is the specific access destination, and obtains decision information (in this embodiment, the authentication result by the authentication server 600) for determining whether or not to approve the service usage request (S320 in Figure 13(A)). With this configuration, the administrator only needs to send the access information to the account management server 400 in advance, thus reducing the burden on the device administrator.

[0137] Furthermore, according to this embodiment, the specific access destination is an authentication server 600, which is a communication device different from servers 300 to 500, and the approval information is a URL that points to the communication device. By simply having the administrator send the URL to the account management server 400 in advance, the account management server 400 can decide whether or not to approve the service usage request by accessing the communication device, thus reducing the burden on the printer 100 administrator.

[0138] More specifically, the communication device is an authentication server 600 that manages the authentication information of users of terminal device 200B. The authentication server 600 communicates with terminal device 200B without going through servers 300 to 600 and performs authentication processing using authentication information (ID and password in this embodiment) (S420, S430 in Figure 14(A)), and sends the result of the authentication processing to the account management server 400 (S440 in Figure 14(A)). The account management server 400 then decides whether or not to approve the service usage request based on the result of the authentication processing by the authentication server 600 (S320 to S350 in Figure 13(A)). As a result, administrators and general users do not need to send authentication information to the account management server 400, so security problems are less likely to occur and it is easier to use services that use printer 100. In addition, the business operator providing the printing service (the business operator operating servers 300 to 500) does not need to manage the authentication information of administrators and general users, so the burden on the business operator is reduced.

[0139] C. Variations (1) In the first embodiment, a password is used as the approval information, but other information may be used. For example, in the first embodiment, when the condition for approval is that the approval information and specific information entered by the applicant are a perfect match, the approval information used may be, for example, an application number assigned to each user who is a candidate for an applicant. The application number is provided to each general user by the administrator, for example, in the same way as the password. In this case, for example, a list of application numbers is sent from the administrator's terminal device 200A to the account management server 400.

[0140] (2) In the second embodiment, a domain name is used as the approval information, but other information may be used. For example, in the case where the approval condition is that the approval information and the specific information entered by the applicant partially match, as in the second embodiment, the following examples of approval information may be used. For example, if the employee ID includes a department code or a code indicating the year of joining the company, the approval information may be the department code or the code indicating the year of joining the company. This example is useful, for example, when allowing employees belonging to a specific department or employees who joined the company in a specific year to use the printing service. In this case, for example, a general user can send their employee ID as specific information from the terminal device 200B to the account management server 400 when applying for use.

[0141] Furthermore, the approval information used in the second embodiment is a domain name, which is part of the personal information of a general user, such as an email address. Alternatively, the approval information may be part of the information assigned to each user by the administrator (for example, an application number).

[0142] (3) In the third embodiment, a URL is used as the authorization information, but other information may be used. For example, if information indicating a specific access destination is used as authentication information, as in the third embodiment, the IP address indicating the specific access destination may be used as the authorization information.

[0143] (4) In the third embodiment, the authentication process is performed by the authentication server 600. Alternatively, the account management server 400 may obtain the authentication information by accessing the memory or server where the authentication information is stored and perform the authentication process based on the authentication information. For example, when operating servers 300 to 500 within the network of a specific organization (e.g., a company) to provide printing services within that organization, the memory where the authentication information is stored may be the storage device of the account management server 400 itself or the storage device of a file server within the organization. In this case, the authorization information may be, for example, the path to the authentication information file stored in the storage device.

[0144] (5) In each of the above embodiments, the service usage request and application-related information (password and email address) are sent from the terminal device 200B to the account management server 400 via the web server 500. Alternatively, the service usage request and application-related information (password and email address) may be sent by email, with the general user's email address as the sender, to a predetermined email address for service usage requests. In particular, as in the second embodiment, if the specific information used for the approval judgment process is an email address, the account management server 400 only needs to use the sender's email address as the specific information to perform the approval judgment process. For this reason, general users can easily send service usage requests to the account management server 400 without including specific information in the content of the email.

[0145] Furthermore, service usage requests and application-related information may be sent from the printer 100 to the account management server 400 when the user inputs a send command via the printer's control panel 150. Even in this case, the device token may be sent to the user's terminal device 200B using an email address.

[0146] (6) In each of the above embodiments, the transmission of application-related information (password and email address) is performed by displaying the application screen (W2 or W2b) on the display unit 240 of the terminal device 200B and transmitting the information entered by the user on the application screen to the web server 500. Alternatively, for example, the terminal device 200B may transmit the application-related information pre-stored in the non-volatile storage device 230 to the web server 500 or the account management server 400.

[0147] (7) In each of the above embodiments, after the administrator's account is registered in response to a service request from the terminal device 200A (S24 in Figure 3), the approval information entered in the approval information input screens (W2, W2b, W2c) is sent from the terminal device 200A to the account management server 400. Alternatively, the approval information may be sent from the terminal device 200A to the account management server 400 at the same time as the service request from the terminal device 200A. In this case, for example, an approval information input field is added to the account information input screen W1 in Figure 5(A), and the user of the terminal device 200A enters the approval information before sending the service request.

[0148] (8) In each of the above embodiments, the device token for general users is sent to the terminal device 200B by sending a token acquisition URL to the email address entered on the application screen W3. Alternatively, the device token for general users may be sent to the terminal device 200B by other means, such as push notification to the terminal device 200B or by attaching the device token for general users to an email address.

[0149] (9) In each of the above embodiments, the example given is that a service request for a printing service provided using the printer 100 is sent from the terminal device. However, service requests for services using other devices may also be sent from the terminal device. As an example of a service using other devices, a service may be adopted in which other devices (e.g., electrical appliances such as surveillance cameras and cooking appliances) set up in a home or office are remotely controlled using the terminal device (terminal application).

[0150] (10) In the above embodiment, the three servers 300, 400, and 500 cooperate to perform communication with terminal devices 200A and 200B, generate and send device tokens, register corresponding accounts, and perform approval judgment processing. Alternatively, the processing performed by the three servers 300, 400, and 500 may be performed by a single server. Furthermore, the processing performed by the three servers 300, 400, and 500 may be performed by two servers 300 and 400, by having either the device management server 300 or the account management server 400 perform the processing that the web server 500 would normally perform.

[0151] (11) In the above embodiment, some of the configurations implemented by hardware may be replaced with software, and conversely, some or all of the configurations implemented by software may be replaced with hardware.

[0152] The present invention has been described above based on examples and modifications. However, the embodiments of the invention described above are for the purpose of facilitating understanding of the present invention and do not limit it. The present invention can be modified and improved without departing from its spirit and claims, and the present invention includes equivalents thereof. [Explanation of Symbols]

[0153] 100…Printer, 1000…System, 110…CPU, 120…Volatile memory, 130…Non-volatile memory, 140…Display unit, 150…Operation unit, 170…Printing mechanism, 200…Terminal device, 200A, 200B…Terminal device, 210…CPU, 220…Volatile memory, 230…Non-volatile memory, 240…Display unit, 250…Operation unit, 300…Device management server, 310…CPU, 320…Volatile memory, 330…Non-volatile memory, 400…Account management server, 410… CPU, 420…Volatile memory, 430…Non-volatile memory, 500…Web server, AP…Application program, AT…Account table, DT…Device table, IB…Information database, 180, 280, 380, 480…Communication interface, MAT…Email address table, MT…Administrator table, PG1, PGa, PGb, PGc…Computer program, TBa…Device management table, TBa…Account management table, TT…Device token table

Claims

1. It is a server, A first recording unit records device identification information that identifies a specific device and administrator identification information that identifies the administrator of the specific device in a memory, in association with each other. A first receiving unit that receives approval information from an administrator terminal device used by the aforementioned administrator, A second recording unit records the received approval information in memory in association with the device identification information, A second receiving unit that receives a usage request from a user terminal device used by a user, wherein the usage request is the first request by the user to use the service using the specific device, A determination unit that determines whether or not to approve the request for use using the approval information in response to the request for use, When approving the aforementioned request for use, a transmission unit transmits the service usage information, which the user uses to use the service and which is associated with the specific device, to the user terminal device. A server equipped with the following features.

2. A server according to claim 1, The second receiving unit further receives specific information from the user terminal device, The determination unit is a server that determines whether or not to approve the usage request using the approval information and the specific information.

3. The server according to claim 2, The server determines, when the specified information and the approval information match, to approve the usage request.

4. The server according to claim 3, The aforementioned authorization information is a password notified to the user by the administrator, on the server.

5. The server according to claim 2, The server determines, when a part of the specific information matches the approval information, to approve the usage request.

6. The server according to claim 5, The aforementioned specific information is information owned by the user, namely the server.

7. The server according to claim 6, The aforementioned specific information is an email address. The aforementioned authorization information is the domain name of the aforementioned email address, which is the server.

8. A server according to claim 1, The aforementioned authorization information is access information that indicates a specific access destination. The determination unit is a server that uses the access information to obtain determination information for determining whether or not to approve the usage request by accessing the specific access destination.

9. The server according to claim 8, The aforementioned specific access destination is a communication device different from the server, The aforementioned approval information is a server, which is a URL (Uniform Resource Locator) indicating the communication device.

10. The server according to claim 9, The aforementioned communication device is an authentication device that manages the user's authentication information. The authentication device communicates with the user terminal device without going through the server, performs authentication processing using the authentication information, and transmits the result of the authentication processing to the server. The determination unit is a server that determines whether or not to approve the usage request based on the result of the authentication process.

11. A server according to any one of claims 1 to 10, The first recording unit records the device identification information and the administrator identification information in association with each other in response to a request from the administrator terminal device. The second recording unit is a server that receives the approval information from the administrator terminal device after the device identification information and the administrator identification information have been recorded.

12. A server according to any one of claims 2 to 7, further, The system includes a display control unit that displays an input screen for entering the aforementioned specific information on the user terminal device, The second receiving unit is a server that receives the specific information entered on the input screen from the user terminal device.

13. A server according to any one of claims 2 to 7, 12, The transmitting unit is a server that transmits the service usage information using the specified information.

14. It is a computer program, A first recording function records device identification information that identifies a specific device and administrator identification information that identifies the administrator of the specific device in memory in association with each other. A first receiving function that receives approval information from the administrator terminal device used by the aforementioned administrator, A second recording function records the received approval information in memory in association with the device identification information, A second receiving function that receives a usage request and specific information from a user terminal device used by a user, wherein the usage request is the first request by the user to use the service using the specific device, and the second receiving function A determination function that determines whether or not to approve the request for use in response to the aforementioned request, using the specified information and the approval information, When approving the aforementioned request for use, a transmission function transmits service usage information used by the user to use the service, which is associated with the specific device, to the user terminal device. A computer program that enables a computer to realize something.

Images