Processing apparatus, computer program, and method
The processing apparatus addresses inefficient account registration in image processing systems by implementing a request and registration mechanism that minimizes unnecessary displays and registrations, enhancing account management efficiency.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- BROTHER KOGYO KK
- Filing Date
- 2022-01-31
- Publication Date
- 2026-07-08
AI Technical Summary
Existing image processing systems lack efficient mechanisms for registering accounts in response to usage requests for specific devices, leading to unnecessary display processes and registration of unnecessary accounts.
A processing apparatus that includes a request acquisition unit, identification information acquisition unit, and registration unit to manage device-specific account registration based on user input, displaying appropriate input screens and registering accounts only when necessary.
This approach reduces unnecessary display processes and account registrations, enabling efficient and targeted account management for device-specific services.
Smart Images

Figure 0007886571000001 
Figure 0007886571000002 
Figure 0007886571000003
Abstract
Description
Technical Field
[0001] This specification relates to a processing apparatus, a computer program, and a method for using a service using a specific device.
Background Art
[0002] The image processing server disclosed in Patent Document 1 provides a printing service to a user of a personal computer (also referred to as a PC). For example, the image processing server generates print data using an image file transmitted from a PC, and transmits the print data to a multifunction device to cause the multifunction device to execute printing. The user has an account for logging in to the image processing server and can use the printing service.
Prior Art Documents
Patent Documents
[0003]
Patent Document Ⅰ
Summary of the Invention
Problems to be Solved by the Invention
[0004] This specification discloses a new technology that can register an account in response to a usage request for using a service using a specific device.
Means for Solving the Problems
[0005] The technology disclosed in this specification can be realized as the following application examples.
[0006] [Application Example 1] A processing apparatus comprising: a request acquisition unit that acquires a usage request based on user input, wherein the usage request is the first request by the user to use a service using a specific device; an identification information acquisition unit that acquires device identification information that identifies the specific device; a display processing unit that, when no corresponding account associated with the device identification information is registered, executes a first display processing to display a first input screen for entering account information in response to the usage request, and does not execute the first display processing when the corresponding account is registered; and a registration unit that, when no corresponding account is registered, registers an account based on the account information entered on the first input screen as the corresponding account, associating it with the device identification information.
[0007] According to the above configuration, if a corresponding account associated with the device identification information is not registered, a first display process is executed to display the account information input screen. If a corresponding account is registered, the first display process is not executed. Then, if a corresponding account is not registered, an account based on the account information entered on the input screen is registered as the corresponding account. As a result, the corresponding account can be appropriately registered in response to usage requests for services using a specific device. For example, unnecessary display processes and the registration of unnecessary corresponding accounts can be suppressed. [Application Example 2] The processing apparatus described in Application Example 1, The registration unit is a processing device that, when the corresponding account is not registered, creates a new account based on the account information entered on the first input screen and registers the new account as the corresponding account. [Application Example 3] Apparatus according to Application Example 1 or 2, The processing device is a server capable of communicating with at least one of the user's terminal device and the specific device. The request acquisition unit acquires the usage request by receiving it from either the terminal device or the specific device. The identification information acquisition unit acquires the device identification information by receiving it from either the terminal device or the specific device. The first display process is a process of transmitting information for displaying the first input screen to either the terminal device or the specific device. The first input screen is a processing device that is displayed on the display unit of either the terminal device or the specific device. [Application Example 4] The processing apparatus described in Application Example 3, further, A processing device comprising a transmission unit that, when the corresponding account is not registered, transmits a token to the terminal device for the user to use the service in response to the registration of the corresponding account by the registration unit, and when the corresponding account is registered, transmits the token to the terminal device without the registration of the corresponding account by the registration unit. [Application Example 5] The processing apparatus described in Application Example 4, further, The aforementioned transmitting unit If the aforementioned corresponding account is registered, the account information of the aforementioned corresponding account is used to send an authorization request for the user to use the service to the destination associated with the aforementioned corresponding account. A processing device that transmits the token to the terminal device when a response indicating approval is received in response to the approval request. [Application Example 6] The processing apparatus described in Application Example 5, The display processing unit, when the corresponding account is registered, executes a second display process to display a second input screen for entering user information. The user information is information different from the account information and is related to the user. The approval request includes the user information entered into the second input screen, which is part of the processing device. [Application Example 7] The processing apparatus described in Application Example 6, The transmission unit is a processing unit that transmits the token to the terminal device using the user information. [Application Example 8] Apparatus according to Application Example 6 or 7, The user information is an email address, according to the processing unit. [Application Example 9] The processing apparatus described in any of Application Examples 4 to 8, The aforementioned tokens include Type 1 tokens and Type 2 tokens, The transmitting unit transmits the first type token to the terminal device if the corresponding account is not registered, and transmits the second type token to the terminal device if the corresponding account is registered. The functions available using the aforementioned first type token include a first function and a second function, A processing device whose functions, when using the second type of token, include the first function but do not include the second function. [Application Example 10] The processing apparatus described in any of Application Examples 3 to 9, further, [[ID=5 [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] A sequence diagram illustrating the printing service. [Modes for carrying out the invention]
[0010] A. First Example A-1. Configuration of System 1000 Figure 1 is a block diagram showing the configuration of system 1000. System 1000 comprises a printer 100, terminal devices 200A and 200B owned by the user of printer 100, a device management server 300, an account management server 400, and a web server 500.
[0011] The printer 100 includes a CPU 110, a volatile storage device 120 such as DRAM, and a non-volatile storage device 130 such as a hard disk or flash memory, as the controller of the printer 100. The printer 100 also includes a display unit 140 such as a liquid crystal display for displaying images, an operation unit 150 such as buttons or a touch panel for acquiring user input, a printing mechanism 170, and a communication interface (IF) 180.
[0012] The communication interface 180 is an interface for connecting to the Internet of Things (IT), such as a wired interface compliant with Ethernet® or a wireless interface compliant with the Wi-Fi standard.
[0013] The CPU 110 is a processing unit (processor) that performs data processing. The volatile memory device 120 provides a buffer area for temporarily storing various intermediate data generated when the CPU 110 performs processing. The non-volatile memory device 130 stores the computer program PG1 for controlling the printer 100 and the information database IB, which records various information such as device information, which will be described later.
[0014] In this embodiment, the computer program PG1 is provided pre-stored in the non-volatile storage device 130 during the manufacturing of the printer 100. Alternatively, the computer program PG1 may be provided, for example, by being downloaded from a server connected via the Internet IT, or by being recorded on a CD-ROM or the like.
[0015] 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.
[0016] 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.
[0017] Terminal devices 200A and 200B are computers, such as smartphones. In variations, terminal devices 200A and 200B may be personal computers or tablet computers.
[0018] 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).
[0019] 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.
[0020] 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.
[0021] 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".
[0022] 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 services described later.
[0023] 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®.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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).
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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).
[0037] As shown in Figure 2(B), the administrator table MT records the administrator's account ID and the printer's device ID in a linked manner. This establishes an association between the administrator's account and the printer. An account associated with a specific printer is also called a linked account.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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)).
[0044] 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).
[0045] 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).
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] When the web server 500 receives an account creation request, it sends the account creation request to the account management server 400 via S20.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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)).
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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. This completes the start-up process.
[0061] Through the activation process 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 becomes able to use the printing service using terminal device 200A (terminal application).
[0062] 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.
[0063] The user of terminal device 200B starts the terminal application on terminal device 200B, just 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] 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.
[0068] When terminal device 200B receives a usage application request, it displays the usage application screen W2 on the display unit 240 of terminal device 200B in S66. In this way, since the usage application screen W2 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 W2.
[0069] The application screen W2 in Figure 5(B) includes an input field BX4 and a send button BT1. Input field BX4 is for entering an email address. 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, password, and name, and only need to enter an email address.
[0070] When a user enters their email address on the application screen W2 and presses the send button BT1, terminal device 200B retrieves the email address via the application screen W2 at S68.
[0071] When terminal device 200B obtains an email address, it sends a usage request to the web server 500 via S70. The usage request includes the email address obtained via S68 and the device information received via S54.
[0072] When the web server 500 receives a usage request, it sends the usage request to the account management server 400 via S72.
[0073] 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.
[0074] In S74, the account management server 400 retrieves information on already registered administrators. Specifically, the account management server 400 refers to the administrator table MT to identify the account ID (administrator's device ID) associated with the device ID included in the application. The account management server 400 then refers to the account table AT to retrieve the username and notification token associated with that account ID.
[0075] When the account management server 400 obtains the administrator's information, it sends an access authorization request to the terminal device 200A at S75 in Figure 7. The access authorization request is sent as a push notification using the notification token of terminal device 200A that has been recorded in the account table AT. The access authorization request includes the email address obtained at S68 in Figure 6, that is, the email address of the user of terminal device 200B.
[0076] When terminal device 200A receives a request for authorization, in S76, it displays the authorization / rejection input screen W3 on the display unit 240 of terminal device 200A.
[0077] The approval / rejection input screen W3 in Figure 5(C) includes a message MS1, an email address MA, an approval button BT2, and a rejection button BT3. Message MS1 is a message that notifies the user that a request to use the printer 100 has been received and prompts the user to input whether to approve or reject the request. The approval button BT2 is a UI (user interface) element for inputting approval of the request. The rejection button BT3 is a UI element for inputting rejection of the request. The email address MA is the email address of the requester, in this embodiment, the user of terminal device 200B. The user of terminal device 200A (the administrator of printer 100) can, for example, look at the email address MA to recognize who the requester is and make an appropriate decision on whether to approve or reject the request.
[0078] The following describes the case where a user of terminal device 200A approves the application for use. When the user presses the approval button BT2 on the approval / rejection input screen W3, terminal device 200A receives input indicating approval of the application for use at S77.
[0079] When terminal device 200A receives input indicating approval of the application for use, it sends an approval notification to account management server 400 via S78.
[0080] Upon receiving the user approval notification, 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 user applicant to obtain a device token. The token acquisition URL request includes the device information received in S58.
[0081] 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.
[0082] 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.
[0083] 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 of the applicant (in this embodiment, the email address of the user of terminal device 200B) is sent to the web server 500.
[0084] 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. The reason for sending the token acquisition URL to the email address is that the administrator of the printer 100 approves the usage application by looking at the email address, and this allows the approved user to acquire the device token. For example, if a usage application is made fraudulently using someone else's email address, it can be prevented from the person who made the fraudulent application acquiring the device token.
[0085] 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 application to use printer 100 has been approved and prompts the user to access the token acquisition URL to obtain a device token.
[0086] 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.
[0087] When terminal device 200B receives a token acquisition instruction, it sends a token acquisition request to device management server 300 at S94 in Figure 8. In this embodiment, the token acquisition request is an HTML (Hypertext Markup Language) request specifying the token acquisition URL associated with link LK.
[0088] 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.
[0089] In S98, the device management server 300 sends an authenticated device token associated with a token acquisition URL to the terminal device 200B as a response to a token acquisition request. For example, the device management server 300 sends the authenticated device token as an HTML response to an HTML request which is a token acquisition request.
[0090] 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.
[0091] 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).
[0092] Next, we will explain the case where the user of terminal device 200A does not approve the application for use. Figure 9 shows the sequence diagram for this case. Steps S75 and S76 in Figure 9 are the same as steps S75 and S76 in Figure 7 described above. If the user of terminal device 200A does not approve the application for use, steps S77B to S90B in Figure 8 are executed instead of steps S77 to S92 in Figure 7 and steps S94 to S99 in Figure 8.
[0093] When the user presses the disapproval button BT3 on the approval / disapproval input screen W3 (Figure 5(C)), the terminal device 200A receives input in S77B indicating that the application for use will not be approved (disapproved).
[0094] When terminal device 200A receives input indicating disapproval, it sends a disapproval notification to account management server 400 via S78B.
[0095] When the account management server 400 receives a notice of disapproval, it sends an unavailable notification to the web server 500 via S88B. At the same time, the email address of the applicant (in this embodiment, the email address of the user of terminal device 200B) is sent to the web server 500 along with the unavailable notification.
[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 10 is a sequence diagram illustrating the printing service.
[0099] A-3-1.Printing 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 that print job. 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] A-3-2. Changing settings A user (administrator) of terminal device 200A who has obtained an administrator device token can make changes to the settings related to the printing service. A user (general user) of terminal device 200B who has obtained a general user device token cannot make changes to the settings.
[0108] When a user of terminal device 200A launches the terminal application and inputs a command to display an input screen for changing settings, terminal device 200A (terminal application) displays a setting change instruction input screen (not shown) on the display unit 240 of terminal device 200A in S152. The user can input predetermined setting change instructions related to the printing service via the setting change instruction input screen. Setting change instructions include, for example, setting or changing the maximum number of pages that a single user can print per day, and limiting the available printing modes (monochrome mode, color mode, high-quality mode, etc.).
[0109] In response to user input, terminal device 200A obtains a configuration change instruction in S154. Upon obtaining the configuration change instruction, terminal device 200A sends a configuration change request to the web server 500 in S156. The configuration change request includes the administrator device token obtained during the initial setup process described above.
[0110] When the web server 500 receives a configuration change request, it sends the configuration change request to the device management server 300 in S158.
[0111] When the device management server 300 receives a configuration change request, it executes a token verification process in S160. In the token verification process, the device management server 300 checks whether the device token included in the configuration change request is recorded in the device token table TT (Figure 2(A)). If the device token is recorded, the device management server 300 checks whether the type information associated with the device token in the device token table TT is "administrator". If the type information associated with the device token in the device token table TT is "administrator", the device management server 300 proceeds to S112. By obtaining the device ID, the printer to which the print job will be sent (printer 100 in this embodiment) is identified. Although not shown in the diagram, if the device token included in the print request is not recorded in the device token table TT, and the type information associated with the device token is "general", 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.
[0112] In S162, the device management server 300 performs a configuration change according to the configuration change instruction. For example, the non-volatile storage device 330 of the device management server 300 stores a configuration file (not shown) associated with a device ID, and the device management server 300 changes the configuration information recorded in the configuration file.
[0113] According to the embodiment described above, the web server 500 obtains a service usage request based on user input (S6 in Figure 3). The web server 500 obtains a device ID, which is identification information that identifies the printer 100 (S6 in Figure 3). If the corresponding account, which is an account associated with the device ID, is not registered (i.e., there is no administrator as shown in Figures 3 and 4), the web server 500 performs a display process to display an account information input screen W1 for entering account information in response to the service usage request (S14 in Figure 3). Specifically, in order to display the account information input screen W1 on the terminal device 200A, the web server 500 sends an account information acquisition request to the terminal device 200A. If the corresponding account is registered (i.e., there is an administrator as shown in Figures 6 to 9), the web server 500 does not perform the display process of the account information input screen W1. That is, in this case, the web server 500 does not send an account information acquisition request to the terminal device 200A. If no corresponding account is registered (i.e., no administrator exists as shown in Figures 3 and 4), the account management server 400 registers an account based on the account information entered on the account information input screen W1 as the corresponding account, associating it with the device ID (S24 in Figure 3, administrator table MT in Figure 2(B)).
[0114] As a result, it is possible to appropriately register corresponding accounts in response to service requests for using the printing service with printer 100. For example, it is possible to suppress the display of unnecessary account information input screen W1 and the registration of unnecessary corresponding accounts. For example, if an administrator's corresponding account is already registered, and yet another account is to be registered, it may become necessary to manage an excessive number of account information, which may increase the burden on the printing service provider. For example, since account information includes personal information, it is preferable to keep the number of accounts to be managed small from the perspective of the management burden on the service provider.
[0115] Furthermore, according to this embodiment, if no corresponding account is registered (i.e., no administrator exists as shown in Figures 3 and 4), the account management server 400 creates a new account based on the account information entered on the account information input screen W1 (S22 in Figure 3), and registers the new account as a corresponding account (S24 in Figure 3). As a result, a new account can be registered as a corresponding account. Therefore, for example, even a user who does not have an account can use the printing service as the administrator of the printer 100 by registering a new account.
[0116] Furthermore, according to this embodiment, if no corresponding account is registered (i.e., no administrator exists as shown in Figures 3 and 4), the device management server 300 and the account management server 400 send a device token to the terminal device 200A for the user to use the printing service, in accordance with the registration of the corresponding account (S24 in Figure 3) (S26 in Figure 3 to S32 in Figure 4). Then, if a corresponding account is registered (i.e., an administrator exists as shown in Figures 6 to 9), the device management server 300 and the account management server 400 send a device token to the terminal device 200B without registering the corresponding account (S80 to S98 in Figure 7). As a result, unnecessary registration of corresponding accounts can be suppressed, thus reducing the burden of managing accounts, for example. Also, since general users can use the printing service using the terminal device without registering a corresponding account, user convenience is improved. In addition, since the printing service can be used without entering personal information, the barrier to using the printing service is lowered, and an increase in users can be expected.
[0117] Furthermore, according to this embodiment, if a corresponding account is registered (i.e., an administrator exists as shown in Figures 6 to 9), the account management server 400 uses the notification token (Figure 2(B)) included in the account information of the corresponding account to send an approval request for the user of terminal device 200B to the destination associated with the corresponding account (in this embodiment, the administrator's terminal device 200A) (S75 in Figure 7). When the device management server 300 and the account management server 400 receive a response indicating approval in response to the approval request (S78 in Figure 7), they send a device token to terminal device 200B (S80 in Figure 7 to S98 in Figure 8). As a result, since the device token is sent only when the owner of the corresponding account (specifically, the user of terminal device 200A, who is the administrator) approves the user of terminal device 200B using the print service, it is possible to suppress any disadvantage to the owner of the corresponding account (administrator). Specifically, device tokens can be sent to users that the administrator did not intend to access, such as users the administrator is unaware of or users the administrator wishes to deny access to, thereby preventing these users from using the printing service.
[0118] Furthermore, according to this embodiment, if a corresponding account is registered (i.e., an administrator exists as shown in Figures 6 to 9), the web server 500 executes a display process to display the application screen W2 for entering user information (S64 in Figure 6). Specifically, in order to display the application screen W2 on the terminal device 200B, the web server 500 sends an application request to the terminal device 200B. The acquired user information is different from the account information and is information about the user of the terminal device 200B; in this embodiment, it is an email address. The user information is included in the approval request sent to the terminal device 200A (S75 in Figure 7). As a result, by including the user information in the approval request, the owner (administrator) of the corresponding account can appropriately determine whether or not to approve it. For example, if the administrator finds that the email address included in the approval request is an unknown address, or that the email address belongs to a person who should be denied access, the administrator can disapprove the application.
[0119] Furthermore, in this embodiment, the device management server 300, the account management server 400, and the web server 500 use email addresses to send device tokens for general users to the terminal device 200B (S88, S89 in Figure 7, and S98 in Figure 8). As a result, the device token is properly transmitted to the general user's terminal device 200B.
[0120] In this embodiment, the token acquisition URL is sent to the terminal device 200B by sending it to an email address (S89 in Figure 7), and when the terminal device 200B accesses the token acquisition URL, the device management server 300 sends a device token to the terminal device 200B (S98 in Figure 8). As a result, the device token is sent only after the owner of the email address has been verified, which helps to prevent the unauthorized acquisition of a device token using, for example, someone else's email address.
[0121] Furthermore, in this embodiment, as described above, the user information included in the application for use is an email address. Since email addresses are widely used, general users can easily apply for use using their email address. As a result, the number of users of the printing service can be increased. In addition, administrators can use the email address to determine whether or not to approve the application appropriately. Moreover, general users can easily obtain a device token for general users using terminal device 200B simply by including their email address in the application for use.
[0122] Furthermore, in this embodiment, the device token includes two types of device tokens: an administrator device token and a general user device token (Figure 2(A)). The device management server 300 and the account management server 400 send the administrator device token to terminal device 200A (S26 in Figure 3 to S32 in Figure 4) when no corresponding account is registered (when no administrator exists as shown in Figures 3 and 4), and send the general user device token to terminal device 200B (S80 to S98 in Figure 7) when a corresponding account is registered (when an administrator exists as shown in Figures 6 to 9). The functions available using the administrator device token include the printing function (Figure 10(A)) and the setting change function (Figure 10(B)). The functions available using the general user device token include the printing function (Figure 10(A)) but do not include the setting change function (Figure 10(B)). As a result, it is possible to differentiate the functions available to administrators who own the corresponding accounts and general users who are not administrators. Therefore, for example, the functions available to general users can be appropriately restricted. As a result, the printing service can be operated smoothly. For example, it can be prevented from general users changing settings without administrator permission, which would disrupt the use of the printing service by administrators or other users.
[0123] Furthermore, in this embodiment, the account management server 400 includes a storage unit (specifically, a non-volatile storage device 430) that stores an administrator table MT that records the association between device IDs and account information. The account management server 400 determines whether a corresponding account is registered by determining whether the device ID received from the terminal device 200A is recorded in the administrator table MT (S10 in Figure 3, S60 in Figure 6). As a result, the account management server 400 can easily determine whether a corresponding account is registered based on the device IDs received from the terminal devices 200A and 200B.
[0124] As can be seen from the above explanation, the servers 300, 400, and 500 in this embodiment are examples of servers and processing units. The account information input screen W1 is an example of a first input screen, and the application screen W2 is an example of a second input screen. The function for printing the print service is an example of a first function, and the function for setting print settings is an example of a second function. The device token for administrators is an example of a first type token, and the device token for general users is an example of a second type token.
[0125] C. Variations (1) In the above embodiment, the service usage request is sent to the WEB server 500 and the account management server 400, and the request to display either the account information input screen W1 or the usage application screen W2 (account information acquisition request, usage application request) is executed by the account management server 400. Alternatively, the terminal devices 200A and 200B (terminal applications) may decide whether to display the account information input screen W1 or the usage application screen W2, and the account information input screen W1 and the usage application screen W2 may be displayed based on this decision. In this case, the terminal devices 200A and 200B may receive the administrator table MT from the account management server 400 and determine whether the corresponding account is registered by determining whether the device ID of the printer 100 is recorded in the administrator table MT. Alternatively, the printer 100 may record information indicating whether the corresponding account is registered (for example, a registered flag) when it receives notification from the account management server 400 that the corresponding account has been registered. In this case, terminal devices 200A and 200B may query printer 100 and receive information from printer 100 indicating whether or not the corresponding account is registered (registered notification or flag) to determine whether or not the corresponding account is registered. If terminal devices 200A and 200B determine that the corresponding account is not registered, they display the account information input screen W1, and if they determine that the corresponding account is registered, they display the application screen W2. If terminal devices 200A and 200B determine that the corresponding account is not registered, they may send a registration request including account information and device information to account management server 400, thereby causing account management server 400 to register the corresponding account.
[0126] Thus, the acquisition of service usage requests based on user input, acquisition of device IDs, determination and display of whether to display the account information input screen W1 or the usage application screen W2, and registration of corresponding accounts may all be primarily performed by the terminal applications of terminal devices 200A and 200B. In this modified example, terminal devices 200A and 200B are examples of processing units.
[0127] (2) In the above embodiment, if no corresponding account is registered, a new account is created and the new account is registered as a corresponding account in the account management server 400. Alternatively, account information (account ID and password) of an existing account may be obtained via the account information input screen W1, and the existing account may be registered as a corresponding account in the account management server 400. As an existing account, for example, an account for an existing web service other than the printing service (for example, an account for GOOGLE® or APPLE®) may be used. In this case, for example, the account management server 400 uses the information of the existing account obtained via the account information input screen W1 to access the server that provides the existing web service, confirms the existence of the existing account, and then registers the existing account as a corresponding account.
[0128] (4) In the above embodiment, the web server 500 obtains service usage requests based on user input from terminal devices 200A and 200B. Alternatively, for example, when each user inputs a send command to the printer 100, the printer 100 may send the service usage request and device ID to the account management server 400. In this case, the account information input screen W1 and the usage application screen W2 may be displayed on the display unit 140 of the printer 100 in response to instructions from the account management server 400. Alternatively, in response to instructions from the account management server 400, a QR code (registered trademark) indicating a request to display the account information input screen W1 and the usage application screen W2 may be displayed on the display unit 140 of the printer 100. In this case, the user's terminal device (200A or 200B) will read the QR code (registered trademark) and display the account information input screen W1 and the usage application screen W2 on the user's terminal device.
[0129] (5) In the above embodiment, if a corresponding account is already registered, the application screen W2 is displayed on the terminal device 200B, and the application is sent from the terminal device 200B to the web server 500. Alternatively, if a corresponding account is already registered, the web server 500 may notify the terminal device 200 that the use of the printing service is not permitted. In this case, the display unit 240 of the terminal device 200B will display a message indicating that the use of the printing service is not permitted. In this case, the user of the terminal device 200B will not be able to use the printing service.
[0130] (6) In the above embodiment, when an application for use is made, an approval request for use is sent to the administrator's terminal device 200A, and when the administrator approves the use, a device token for general users is sent to the terminal device 200B of the user who made the application for use. Alternatively, when an application for use is made, an approval request for use may not be sent to the administrator's terminal device 200A, and a device token for general users may be sent to the user's terminal device 200B. In this case, for example, a device token for general users may be sent to any user, or a device token for general users may be sent only to users who have made an application using an email address recorded in a list registered in advance by the administrator.
[0131] (7) In the above embodiment, the user information included in the request for approval of use is an email address. However, the user information included in the request for approval of use may also be other information such as the name of the user who made the request for use or an employee ID.
[0132] (8) In the above embodiment, 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 W2. 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.
[0133] (9) In the above embodiment, two types of device tokens are used, one for administrators and one for general users. Alternatively, only one type of device token may be used. In this case, there does not need to be any difference in the functions available to administrators and general users.
[0134] (10) In the above embodiment, the case in which a service request for a printing service provided using the printer 100 is sent from the terminal device is described as an example. Not limited to printing services, 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).
[0135] (11) In the above embodiment, the three servers 300, 400, and 500 work together to perform tasks such as communication with terminal devices 200A and 200B, generation and transmission of device tokens, and registration of corresponding accounts. Alternatively, the processes performed by the three servers 300, 400, and 500 may be performed by a single server. Furthermore, the processes 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 processes that the web server 500 would normally perform.
[0136] (12) In the above embodiment, some of the configurations implemented by hardware may be replaced with software, or conversely, some or all of the configurations implemented by software may be replaced with hardware.
[0137] 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]
[0138] 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. A server capable of communicating with the user's terminal device, A request receiving unit that receives a usage request from the terminal device based on the user's input, wherein the usage request is the first request by the user to use a service using a specific device, An identification information receiving unit that receives device identification information for identifying the specific device from the terminal device, A display processing unit that, when no corresponding account associated with the device identification information is registered, performs a first display process to send information to the terminal device for displaying a first input screen for entering account information in response to the usage request, and does not perform the first display process when the corresponding account is registered, wherein the first input screen is displayed on the display unit of the terminal device, and the display processing unit and If the aforementioned corresponding account is not registered, the registration unit registers an account based on the account information entered on the first input screen as the corresponding account and associates it with the device identification information. A transmitting unit that, if the corresponding account is not registered, transmits a token to the terminal device for the user to use the service in response to the registration of the corresponding account by the registration unit, and transmits the token to the terminal device without the registration of the corresponding account by the registration unit if the corresponding account is already registered. A processing apparatus equipped with the following features.
2. A server capable of communicating with a user's terminal device and a specific device, A request receiving unit that receives a usage request from the specific device based on the user's input, wherein the usage request is the first request from the user to use a service using the specific device, An identification information receiving unit that receives device identification information that identifies the specific device from the specific device, A display processing unit that, when a corresponding account associated with the device identification information is not registered, executes a first display process to send information for displaying a first input screen for entering account information to the specific device in response to the usage request, and does not execute the first display process when the corresponding account is registered, wherein the first input screen is displayed on the display unit of the specific device, and the display processing unit and If the aforementioned corresponding account is not registered, the registration unit registers an account based on the account information entered on the first input screen as the corresponding account and associates it with the device identification information. A transmitting unit that, if the corresponding account is not registered, transmits a token to the terminal device for the user to use the service in response to the registration of the corresponding account by the registration unit, and transmits the token to the terminal device without the registration of the corresponding account by the registration unit if the corresponding account is already registered. A processing apparatus equipped with the following features.
3. The apparatus according to claim 1 or 2, The registration unit is a processing device that, when the corresponding account is not registered, creates a new account based on the account information entered on the first input screen and registers the new account as the corresponding account.
4. The processing apparatus according to any one of claims 1 to 3, further, The aforementioned transmitting unit If the aforementioned corresponding account is registered, the account information of the aforementioned corresponding account is used to send an authorization request for the user to use the service to the destination associated with the aforementioned corresponding account. A processing device that transmits the token to the terminal device when a response indicating approval is received in response to the approval request.
5. The processing apparatus according to claim 4, The display processing unit, when the corresponding account is registered, executes a second display process to display a second input screen for entering user information on the display unit of the terminal device. The user information is information different from the account information and is related to the user. The approval request includes the user information entered into the second input screen, which is part of the processing device.
6. The processing apparatus according to claim 5, The transmission unit is a processing unit that transmits the token to the terminal device using the user information.
7. The processing apparatus according to claim 5 or 6, The user information is an email address, according to the processing unit.
8. The processing apparatus according to any one of claims 1 to 7, The aforementioned tokens include a first-class token and a second-class token, The transmitting unit transmits the first type token to the terminal device if the corresponding account is not registered, and transmits the second type token to the terminal device if the corresponding account is registered. The functions available using the aforementioned first type token include a first function and a second function, A processing device that includes the first function and does not include the second function, and whose functions are available using the second type of token.
9. The processing apparatus according to any one of claims 1 to 8, further, A storage unit for storing a table that records the device identification information in association with the account information, A processing device comprising a determination unit that determines whether the corresponding account is registered by determining whether the device identification information received from the terminal device is recorded in the table.
10. A computer program for a server that can communicate with a user's terminal device, A request receiving function that receives a usage request from the terminal device based on the user's input, wherein the usage request is the first request by the user to use a service using a specific device, and the request receiving function An identification information receiving function that receives device identification information that identifies the specific device from the terminal device, A display processing function that, when a corresponding account associated with the device identification information is not registered, executes a first display process to send information to the terminal device for displaying a first input screen for entering account information in response to the usage request, and does not execute the first display process when the corresponding account is registered, wherein the first input screen is displayed on the display unit of the terminal device, and the display processing function and If the aforementioned corresponding account is not registered, a registration function is provided to register an account based on the account information entered on the first input screen as the corresponding account, in association with the device identification information. A transmission function that, if the corresponding account is not registered, sends a token to the terminal device for the user to use the service in response to the registration of the corresponding account by the registration function, and if the corresponding account is registered, sends the token to the terminal device without registering the corresponding account by the registration function. A computer program that enables a computer to realize something.
11. A computer program for a server that can communicate with a user's terminal device and a specific device, A request receiving function that receives a usage request from the specific device based on the user's input, wherein the usage request is the user's first request to use a service using the specific device, and the request receiving function An identification information receiving function that receives device identification information from the specific device that identifies the specific device, A display processing function that, when a corresponding account associated with the device identification information is not registered, executes a first display process to send information for displaying a first input screen for entering account information to the specific device in response to the usage request, and does not execute the first display process when the corresponding account is registered, wherein the first input screen is displayed on the display unit of the specific device, and the display processing function If the aforementioned corresponding account is not registered, a registration function is provided to register an account based on the account information entered on the first input screen as the corresponding account, in association with the device identification information. A transmission function that, if the corresponding account is not registered, sends a token to the terminal device for the user to use the service in response to the registration of the corresponding account by the registration function, and if the corresponding account is registered, sends the token to the terminal device without registering the corresponding account by the registration function. A computer program that enables a computer to realize something.