Server and computer program for the server

Abstract

To provide a technique that can switch whether to simultaneously provide a user with two or more services having the same type according to the type of a service whose registration is requested from the user.SOLUTION: When receiving, from an external device, a registration request including first service identification information and specific device identification information, a server determines whether a first service can be provided. When the first service is a first type service not having an exclusive attribute, the server determines that the first service can be provided. When the first service is a second type service having the exclusive attribute and first device identification information and second service identification information for identifying a second service being a second type service different from the first service are stored in association with each other, the server determines that the first service cannot be provided.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] This specification discloses a technique for providing a server-based service to a user of a communication device. [Background technology]

[0002] Patent Document 1 discloses a server that registers a user account of a printer user and a service provided to the user in association with each other. The server further stores a service in association with a category of the service. The server does not simultaneously provide a user with multiple services of the same category. In other words, when a service is associated with a certain user account, the server does not display other services having the same category as the service in association with each other as available services. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2017-068722 A Summary of the Invention [Problem to be solved by the invention]

[0004] There may be cases where a plurality of services of the same category can be simultaneously provided to a user. The techniques in the above documents do not take such cases into consideration. This specification provides a technique that can switch whether or not two or more services of the same type are simultaneously provided to the user, depending on the type of service for which the user requests registration. [Means for solving the problem]

[0005] The server disclosed in the present specification includes a memory that stores, for each of one or more communication devices, device identification information that identifies the communication device and service identification information that identifies a service among a plurality of services that is currently being provided to a user of the communication device in association with each other, the plurality of services including a first type of service that does not have an exclusive attribute and a second type of service that has the exclusive attribute, the exclusive attribute being an attribute that, in a state in which a certain type of service is being provided to a user of a certain communication device, it is impossible to further provide another service of the certain type to the user of the certain communication device, the memory; a registration request receiving unit that receives, from an external device, a registration request including first service identification information that identifies a first service to be provided to a user of a specific communication device and specific device identification information that identifies the specific communication device; and a first determination unit that, when the registration request is received from the external device, determines whether the first service can be provided to the user of the specific communication device, and if the first service is the first type of service, determines whether the first service can be provided to the user of the specific communication device. the first determination unit determines that the first service can be provided when the first service is the second type of service and the first device identification information and service identification information identifying the second type of service different from the first service are not stored in the memory in an associated manner, and determines that the first service cannot be provided in a specific case when the first service is the second type of service and the first device identification information and second service identification information identifying a second service that is the second type of service different from the first service are stored in the memory in an associated manner; and a first storage control unit that stores the first service identification information in the memory in association with the first device identification information when it is determined that the first service can be provided.

[0006] According to the above configuration, if the first service requested to be registered by the user is a first type service that does not have an exclusive attribute, the server determines that the first service can be provided even if another first type service has already been provided to the user, and stores the first service identification information in the memory in association with the first device identification information. On the other hand, if the first service requested to be registered by the user is a second type service that has an exclusive attribute, the server determines that the first service cannot be provided if a second type service different from the first service has already been provided to the user. Thus, the server can switch between whether or not to simultaneously provide two or more services of the same type to the user depending on the type of the first service requested to be registered.

[0007] A computer program for the above server, a computer-readable storage medium storing the computer program, and a method executed by the above server are also novel and useful. [Brief description of the drawings]

[0008] [Figure 1] 1 shows the configuration of a communication system. [Diagram 2] 2 shows the hardware configuration of the intermediation server and the printer. [Diagram 3] 2 shows a printer registration sequence. [Figure 4] 3 and the service registration sequence. [Diagram 5] 1 shows a flowchart of a service registration process. [Figure 6] A specific case sequence is shown. [Figure 7] The sequence continues from FIG. [Figure 8] The sequence continues from FIG. [Figure 9] This shows a continuation of the sequence in FIG. [Figure 10] The sequence continues from FIG. [Figure 11] The service stop sequence is shown. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] (Configuration of communication system 2: Figure 1) The communication system 2 includes a printer 100, a terminal 6, an intermediary server 10, and a plurality of service providing servers (hereinafter referred to as "SP (short for Service Providing) servers") 1A to 3B. Each device is connected to the Internet 8 and can communicate with each other via the Internet 8.

[0010] The terminal 6 is a user terminal used by the user of the printer 100. The intermediary server 10 executes various communications for the user of the printer 100 to receive services from the SP server 1A and the like. Each of the SP servers 1A to 3B is installed on the Internet 8 by the vendor of the printer 100 or a business operator other than the vendor. Each of the SP servers 1A and 1B provides a remote printing service. The remote printing service is a service that causes the printer 100 to execute printing according to image data received from the terminal 6. Each of the SP servers 2A to 2C provides an automatic consumables shipping service. The automatic consumables shipping service is a service that automatically ships new consumables when the remaining amount of consumables in the printer 100 becomes low. Each of the SP servers 3A and 3B provides a product warranty service. The product warranty service is a service that performs maintenance, warranty, etc. of the printer 100.

[0011] (Configuration of the intermediary server 10; Figure 2) The intermediation server 10 is installed on the Internet 8 by the vendor of the printer 100. The intermediation server 10 comprises a communication interface (hereinafter, the interface will be referred to as "I / F") 12 and a control unit 30. Each unit 12, 30 is connected to a bus line (reference numerals omitted). The communication I / F 12 is connected to the Internet 8. The control unit 30 comprises a CPU 32 and a memory 34. The CPU 32 executes various processes according to a program 36 stored in the memory 34. The memory 34 is composed of a volatile memory, a non-volatile memory, etc. The memory 34 stores a service type table 50, a registration management table 52, and a transition management table 54.

[0012] The service type table 50 stores a service ID, a service type, and an exclusive attribute in association with each other. The contents stored in the service type table 50 are determined in advance by the vendor of the printer 100. The service ID is information (for example, a service name) that identifies a service provided by each of the SP servers 1A to 3B. A service ID is assigned to each of the SP servers 1A, etc. The SP servers 1A and 1B are assigned service IDs "XXA" and "XXB", respectively. The SP servers 2A to 2C are assigned service IDs "YYA" to "YYC", respectively. The SP servers 3A and 3B are assigned service IDs "ZZXA" and "ZZB", respectively. In the following, the service identified by the service ID "XXA" may be simply referred to as "service "XXA". Other services may also be described in a similar manner.

[0013] The service type is information that indicates the type (i.e., category) of the service. In this embodiment, a remote printing service may be described as type "Remote", an automatic consumables shipping service may be described as type "Supply", and a product warranty service may be described as type "Warranty".

[0014] The exclusive attribute is information indicating whether or not multiple services of the same type can be simultaneously provided to a user via the same printer. The presence or absence of the exclusive attribute is set for each service type. The type "Remote" has the exclusive attribute "absent". This means that two remote printing services corresponding to two SP servers 1A and 1B can be simultaneously provided to a user via the same printer. The type "Supply" has the exclusive attribute "present". This means that three consumable automatic delivery services corresponding to three SP servers 2A to 2C cannot be simultaneously provided to the same user. If a user uses a certain consumable automatic delivery service for the printer 100, the user can automatically obtain new consumables when the remaining amount of consumables in the printer 100 becomes low. Therefore, the user does not need to use other consumable automatic delivery services in addition to the certain consumable automatic delivery service. For this reason, the type "Supply" is set to the exclusive attribute "present". Like the type "Supply", the type "Warrantly" also has the exclusive attribute "present".

[0015] The registration management table 52 stores a printer ID for identifying a printer, a service ID for identifying a service currently being provided to a user of the printer, and a service type of the service in association with each other. Each time a service is started to be provided to a user of the printer, each piece of information is stored in the registration management table 52.

[0016] The transition management table 54 stores a service ID, a service type, a transferable ID, and a registration process in association with each other. The contents stored in the transition management table 54 are determined in advance by the vendor of the printer 100. The transferable ID is information for identifying a service of the same type that can be transferred from a certain service of a type having an exclusive attribute. For example, in the transition management table 54, a transferable ID "YYB" is stored in association with a service ID "YYA". This means that the service "YYA" can be transferred to the service "YYB". On the other hand, a transferable ID is not associated with the service ID "YYB". This means that the service "YYB" cannot be transferred to another consumable automatic delivery service (for example, "YYA", "YYC"). Whether or not a service can be transferred to another service depends on the content of each service. For example, in a consumable automatic delivery service, it is possible to transfer from a service that charges for each delivery of one consumable to a service that charges a fixed amount for each contract period regardless of the number of consumables delivered. On the other hand, it may not be possible to switch from the latter service to the former service, since it may not be possible to cancel the service before the contract period expires.

[0017] The registration process is a process that should be executed when the SP server starts providing a service. In the transition management table 54, a dedicated ink setting process is stored as a registration process in association with each of the service IDs "YYA" and "YYB". This means that each of the SP servers 2A and 2B executes the same dedicated ink setting process when it starts providing each of the services "YYA" and "YYB".

[0018] (Configuration of printer 100; Fig. 2) Printer 100 is a peripheral device (i.e., a peripheral device of terminal 6) capable of executing a printing function. Note that printer 100 may be a multi-function device capable of executing a scanning function, a FAX function, etc. in addition to a printing function. Printer 100 includes an operation unit 124, a display unit 126, a print execution unit 118, a communication I / F 112, and a control unit 130. As shown in FIG. 1, printer 100 is assigned a printer ID "PPP."

[0019] The operation unit 124 includes a plurality of keys. A user can input various instructions to the printer 100 by operating the operation unit 124. The display unit 126 is a display for displaying various information. The display unit 126 also functions as a so-called touch panel (i.e., an operation unit). The print execution unit 118 is a printing mechanism such as an inkjet type or a laser type. The communication I / F 112 is connected to the Internet 8 via a LAN (abbreviation for Local Area Network) (not shown).

[0020] The control unit 130 includes a CPU 132 and a memory 134. The CPU 132 executes various processes in accordance with a program 136 stored in the memory 134. The memory 134 is configured by a volatile memory, a non-volatile memory, or the like.

[0021] The printer 100 performs printing using color materials by installing a consumable color material cartridge (hereinafter, the cartridge will be referred to as "CTG"). In this embodiment, the printer 100 can print using either a dedicated CTG or a general-purpose CTG that is different from the dedicated CTG. The dedicated CTG is a CTG dedicated to receiving the provision of the service "YYA" or the service "YYB". The general-purpose CTG is a CTG that is used when these services "YYA" and "YYB" are not provided.

[0022] (Printer registration sequence; Figure 3) Next, the process for registering information about the printer 100 in the relay server 10 will be described with reference to Fig. 3. Note that, in the following, for ease of understanding, the processes executed by the CPU (e.g., CPU 32) of each device (e.g., relay server 10) will be described as the subject of each device (e.g., relay server 10) rather than the subject of each CPU. Also, all of the following communications executed by the relay server 10 and printer 100 are executed via communication I / Fs 12 and 112. Therefore, in the following, when describing the processes related to communication, the phrase "via communication I / F 12 (or 112)" will be omitted.

[0023] At T10, the terminal 6 accepts an account registration operation from the user. The account registration operation includes the user inputting the URL (short for Uniform Resource Locator) of a desired SP server. Hereinafter, the SP server in question will be referred to as the "target SP server."

[0024] When the terminal 6 accepts the account registration operation in T10, it transmits an account registration request to the target SP server in T12. As a result, the terminal 6 receives registration screen data from the target SP server in T20, and displays the registration screen in T30.

[0025] Next, the terminal 6 accepts input of various information in T32. The information differs depending on the service provided by the target SP server. For example, if the target SP server is the SP server 2A that provides a consumables automatic delivery service, the information includes an email address MA, a password PW, an address AD, and billing information CI such as a credit card number. For example, if the target SP server is the SP server 1A that provides a remote printing service, the information includes an email address MA and a password PW (i.e., a user account), but does not include an address AD and billing information CI. The terminal 6 transmits the input information to the target SP server in T34. Note that, in a modified example, if the target SP server is the SP server 1A that provides a remote printing service, the information input in T32 may include an address AD and billing information CI.

[0026] When the target SP server receives the information from the terminal 6 in T34, it registers a user account UA1 (hereinafter simply referred to as "UA1") including the information in T40. Next, the target SP server transmits an account request to the intermediate server 10 in T50.

[0027] When the intermediary server 10 receives an account request from the target SP server in T50, the intermediary server 10 generates an intermediary server account SA1 (hereinafter simply referred to as "SA1") in T52. Then, the intermediary server 10 transmits the SA1 to the target SP server in T54.

[0028] When the target SP server receives SA1 from the relay server 10 in T54, it stores SA1 in association with UA1 in T56. This allows SA1 to be shared by the target SP server and the relay server 10. Thereafter, the target SP server transmits an account registration result indicating that UA1 has been registered to the terminal 6 in T60.

[0029] When the terminal 6 receives the account registration result from the target SP server in T60, the terminal 6 displays the account registration result in T62. Next, the terminal 6 accepts a printer registration instruction from the user in T70. In this case, the terminal 6 transmits a printer registration request to the target SP server in T72. Note that in a modified example, the terminal 6 may transmit the printer registration request including UA1 to the target SP server in T72.

[0030] When the target SP server receives the printer registration request from the terminal 6 in T72, it transmits a PIN request including SA1 to the relay server 10 in T74.

[0031] When the intermediary server 10 receives a PIN request from the target SP server in T74, it generates a PIN code C1 (hereinafter simply referred to as "PC1") in T76. The intermediary server 10 then associates SA1 included in the PIN request with the generated PC1 and stores it. Next, the intermediary server 10 transmits PC1 to the terminal 6 via the target SP server in T78.

[0032] When the terminal 6 receives PC1 from the target SP server in T78, it displays PC1 in T80, thereby allowing the user to know PC1.

[0033] (Continuation of Figure 3; Figure 4) In T100, the printer 100 accepts an input of PC1 from the user. In this case, in T102, the printer 100 transmits a printer registration request including PC1 and the printer ID "PPP" (hereinafter simply referred to as "PPP") to the intermediation server 10.

[0034] When the intermediary server 10 receives a printer registration request from the printer 100 in T102, it first identifies the SA1 (see T76 in FIG. 3) associated with the PC1 included in the printer registration request. Then, in T104, the intermediary server 10 associates the identified SA1 with the PPP included in the printer registration request and stores them. After that, in T110, the intermediary server 10 generates an access token AT1 (hereinafter simply referred to as "AT1") and stores AT1 in association with the SA1 and the PPP.

[0035] Next, in T112, the intermediation server 10 transmits AT1 to the printer 100. As a result, in T114, an XMPP (short for eXtensible Messaging and Presence Protocol) connection is established between the intermediation server 10 and the printer 100. By using the XMPP connection, the intermediation server 10 can transmit a signal to the printer 100 across the firewall of the LAN to which the printer 100 belongs, even without receiving a request from the printer 100. Next, in T120, the intermediation server 10 transmits notification information including SA1 and PPP to the target SP server.

[0036] When the target SP server receives the notification information from the intermediation server 10 in T120, it first confirms that UA1 and SA1 are associated with each other (see T56 in FIG. 3) by using SA1 included in the notification information. Then, in T122, the target SP server stores the PPP included in the notification information in association with UA1 and SA1. After that, in T130, the target SP server transmits to the terminal 6 a printer registration result indicating that the information of the printer 100 has been registered in the intermediation server 10. The printer registration result includes the PPP stored in T122 and one or more service IDs that identify one or more services that the target SP server can provide. In this embodiment, it is assumed that each of the SP servers 1A to 3C can provide only one service. Therefore, the printer registration result includes only one service ID corresponding to the target SP server.

[0037] When the terminal 6 receives the printer registration result from the target SP server in T130, it displays the printer registration result (that is, the PPP and service ID) in T132.

[0038] (Service registration sequence; Figure 4) In T140, the terminal 6 accepts from the user a selection of a PPP included in the printer registration result and a selection of a service ID included in the printer registration result. In this case, in T142, the terminal 6 transmits a service registration request including the PPP and the selected service ID to the target SP server. In a modified example, the terminal 6 may transmit a service registration request further including UA1 to the target SP server in T142.

[0039] When the target SP server receives the service registration request from the terminal 6 in T142, it first identifies the SA1 (see T122) associated with the PPP included in the service registration request. Next, in T144, the target SP server transmits the service registration request further including the SA1 to the intermediate server 10.

[0040] When the intermediation server 10 receives the service registration request from the target SP server in T144, the intermediation server 10 executes a service registration process. The service registration process is a process for registering the printer ID, the service ID, and the service type in the registration management table 52.

[0041] (Service registration process; Figure 5) Next, the service registration process executed by the CPU 32 of the intermediation server 10 will be described with reference to Fig. 5. As described above, the service registration process is triggered by receiving a service registration request from a target SP server. The service registration request includes the intermediation server account, the printer ID, and the selected service ID.

[0042] In S10, the CPU 32 judges whether or not the service identified by the selected service ID has an exclusive attribute. Specifically, if the selected service ID is associated with the exclusive attribute "Yes" in the service type table 50, the CPU 32 judges that the service has an exclusive attribute (YES in S10) and proceeds to S30. On the other hand, if the selected service ID is associated with the exclusive attribute "No", the CPU 32 judges that the service does not have an exclusive attribute (NO in S10) and proceeds to S12.

[0043] In S12, the CPU 32 registers the selected service ID in the registration management table 52. Specifically, the CPU 32 first identifies the service type associated with the selected service ID from the service type table 50. The CPU 32 then associates the PPP included in the service registration request with the selected service ID and the identified service type, and stores them in the registration management table 52. When S12 ends, the CPU 32 proceeds to S20.

[0044] In S20, the CPU 32 transmits to the target SP server a service registration notification indicating that information such as the service ID has been registered. When S20 ends, the processing of FIG.

[0045] In S30, CPU 32 identifies one or more service IDs (hereinafter referred to as "registered service IDs") associated with the PPP included in the service registration request from registration management table 52. Note that if there is no service ID associated with the PPP, CPU 32 does not identify any registered service IDs.

[0046] In S32, the CPU 32 judges whether the service type of the registered service ID (hereinafter referred to as the "registered type") and the service type of the selected service ID (hereinafter referred to as the "selected type") match. If the CPU 32 has not specified a registered service ID in S30, it judges NO in S32 and proceeds to S12. If the CPU 32 has specified one or more registered service IDs in S30, it executes the following process. That is, the CPU 32 specifies one or more registered types corresponding to one or more registered service IDs from the service type table 50, and specifies a selected type from the service type table 50. Then, if the selected type is included in the one or more registered types, the CPU 32 judges YES in S32 and proceeds to S40, and if the selected type is not included in the one or more registered types, it judges NO in S32 and proceeds to S12.

[0047] Hereinafter, a registered service ID of the same service type as the selected service ID is referred to as a "specific service ID". In S40, the CPU 32 judges whether or not a transition from a service identified by the specific service ID (hereinafter referred to as a "specific service") to a service identified by the selected service ID (hereinafter referred to as a "selected service"). Specifically, the CPU 32 judges whether or not a specific service ID is stored as a "service ID" in the transition management table 54, and a selected service ID is stored as a "transferable ID" associated with the specific service ID. If the selected service ID is stored in association with the specific service ID, the CPU 32 judges that a transition from the specific service to the selected service is possible (YES in S40), and proceeds to S42. On the other hand, if the selected service ID is not stored in association with the specific service ID, the CPU 32 judges that a transition from the specific service to the selected service is not possible (NO in S40), and proceeds to S50.

[0048] In S50, the CPU 32 transmits to the target SP server a service registration notification indicating that information such as the service ID has been registered. When S50 ends, the processing in FIG.

[0049] In S42, the CPU 32 transmits inquiry screen data to the target SP server. The inquiry screen data is data representing an inquiry screen for inquiring the user as to whether or not to transition from the specific service to the selected service. As a result, the inquiry screen data is transmitted from the target SP server to the terminal 6, and the inquiry screen is displayed on the terminal 6.

[0050] In S44, the CPU 32 receives the selection result on the inquiry screen from the terminal 6 via the target SP server.

[0051] In S60, the CPU 32 judges whether or not the selection result indicates "transition." If the selection result indicates "transition," the CPU 32 judges YES in S60 and proceeds to S62, and if the selection result does not indicate "transition," the CPU 32 judges NO in S60 and proceeds to S50.

[0052] In S62, the CPU 32 deletes the PPP, the specific service ID, and the service type associated therewith, included in the service registration request, from the registration management table 52. The CPU 32 further associates the PPP, the selected service ID, and the service type in the registration management table 52, in the same manner as in S12. This allows the transition of services of the same service type to be realized.

[0053] In S70, the CPU 32 judges whether the service before the transition (i.e., the specified service) and the service after the transition (i.e., the selected service) are to execute the same registration process. Specifically, the CPU 32 identifies the registration process associated with the specified service ID and the registration process associated with the selected service ID from the transition management table 54. If the two identified processes match, the CPU 32 judges YES in S70 and proceeds to S82, and if the two identified processes do not match, the CPU 32 judges NO in S70 and proceeds to S72.

[0054] In S72, the CPU 32 sends a service registration notification to the target SP server. Also, in S74, the CPU 32 sends a service stop notification to the SP server providing the specific service (hereinafter, the "specific SP server") to stop the provision of the service. When S74 ends, the processing of FIG. 5 ends. Note that in a modified example, the CPU 32 may send a service registration notification including a setting instruction to the target SP server in S72. The setting instruction is an instruction indicating that a process to change the printer settings is required when the provision of the service is started. Also, the CPU 32 may send a service stop notification including a setting instruction to the specific SP server in S74. The setting instruction is an instruction indicating that a process to change the printer settings is required when the provision of the service is stopped.

[0055] In S82, the CPU 32 transmits a service registration notification including a setting-free instruction to the target SP server. The setting-free instruction is an instruction indicating that the process of changing the printer settings is not required when the provision of the service is started. In addition, in S84, the CPU 32 transmits a service stop notification including a setting-free instruction to the specific SP server. The setting-free instruction is an instruction indicating that the process of changing the printer settings is not required when the provision of the service is stopped. When S84 ends, the process of FIG. 5 ends.

[0056] (Specific case; Figure 6) Next, a specific case realized by the processing in Fig. 5 will be described. Fig. 6 shows a case where the target SP server is SP server 2A. In the initial state in Fig. 6, UA1, SA1, and PPP are stored in association with each other in SP server 2A (see T122 in Fig. 4). Moreover, PPP and a service ID are not stored in association with each other in registration management table 52 of relay server 10.

[0057] When the SP server 2A receives a service registration request including PPP and the service ID "YYA" from the terminal 6 at T142 in FIG. 4, it sends a service registration request including SA1, PPP, and the service ID "YYA" to the intermediary server 10 at T200 in FIG. 6 (i.e., T144 in FIG. 4).

[0058] When the intermediary server 10 receives a service registration request from the SP server 2A in T200 (triggering the process in FIG. 5), it uses the service type table 50 to determine that the service ID "YYA" included in the service registration request is associated with the exclusive attribute "Yes" (YES in S10). Next, the intermediary server 10 uses the registration management table 52 to determine that there is no registered service ID associated with the PPP (NO in S32). Therefore, in T202, the intermediary server 10 associates the PPP with the service ID "YYA" and the type "Supply" and stores them in the registration management table 52 (S12). Next, in T204, the intermediary server 10 transmits a service registration notification to the SP server 2A (S20).

[0059] Next, a process in which the SP server 2A provides the consumables automatic delivery service after the process in FIG. 5 will be described. The SP server 2A transmits a Subscribe request to the intermediary server 10 at T210. The Subscribe request includes timing information, a PPP, and a dedicated setting instruction. The timing information is information indicating the timing at which consumables information indicating the remaining amount of color material in the CTG installed in the printer 100 should be transmitted to the intermediary server 10, for example, a predetermined time in a day. The dedicated setting instruction is an instruction to change the settings of the printer 100, and specifically, an instruction to change the settings of the printer 100 from a setting in which a general-purpose CTG can be used to a setting in which only a dedicated CTG can be used (hereinafter referred to as "dedicated ink setting"). The process in which the SP server 2A transmits a Subscribe request including a dedicated setting instruction to the intermediary server 10 is the registration time process "dedicated ink setting" stored in the transition management table 54.

[0060] When the relay server 10 receives the Subscribe request from the SP server 2A in T210, it transmits the Subscribe request to the printer 100 in T212 by using the XMPP connection (see T144 in FIG. 4).

[0061] When the printer 100 receives the Subscribe request in T212, it changes the settings in accordance with the dedicated setting instruction in T214. Specifically, the printer 100 changes the settings from a setting that allows the use of a general-purpose CTG to a dedicated ink setting that allows the use of only the dedicated CTG. As a result, the printer 100 is able to print when the dedicated CTG is installed, but is unable to print when the general-purpose CTG is installed.

[0062] When the terminal 6 receives, in T220, a registration completion notification indicating that the service ID "YYA" has been registered from the SP server 2A, in T222, the terminal 6 displays the registration completion notification.

[0063] In T230, the printer 100 determines that the timing indicated by the timing information included in the Subscribe request has arrived. In this case, the printer 100 transmits the consumables information including the PPP to the relay server 10 in T232.

[0064] When the relay server 10 receives the consumable information from the printer 100 in T232, the relay server 10 identifies the service ID "YYA" (see T202) associated with the PPP included in the consumable information from the registration management table 52. Then, in T234, the relay server 10 transmits the consumable information to the SP server 2A corresponding to the identified service ID "YYA."

[0065] When the SP server 2A receives the consumables information from the intermediary server 10 in T234, it compares the remaining amount of the dedicated CTG included in the consumables information with a threshold in T240. The SP server 2A determines that the remaining amount is less than the threshold in T240, and executes a shipping process to ship a new consumable (i.e., a dedicated CTG) in T242. Specifically, the SP server 2A identifies UA1 associated with the PPP included in the consumables information (see T122 in FIG. 4), and ships the consumables to the address AD included in UA1. Then, the SP server 2A performs charging using the charging information CI included in UA1. This realizes an automatic consumables shipping service.

[0066] (Continuation of Figure 6; Figure 7) Next, referring to Fig. 7, a continuation of the case in Fig. 6 will be shown. Fig. 7 shows a case where the target SP server is SP server 2C. In the initial state in Fig. 7, PPP, YYA, and the type "Supply" are stored in registration management table 52 of relay server 10 (see T202 in Fig. 6). Also, SA1, PPP, and AT1 are stored in association with each other in relay server 10 (see T110 in Fig. 4).

[0067] First, the same processes as T10 to T80 in Fig. 3 are executed. However, here, instead of UA1, a user account UA2 (hereinafter simply referred to as "UA2") is used. As a result, the SP server 2C associates UA2 with the relay server account SA2 (hereinafter simply referred to as "SA2") and stores them, similar to T56 in Fig. 3. Also, the relay server 10 generates a PIN code C2 (hereinafter simply referred to as "PC2") and associates SA2 with PC2 and stores them, similar to T76.

[0068] In T300, the printer 100 accepts from the user an input of PC2 displayed on the terminal 6. In this case, the printer 100 transmits a printer registration request including PC2 and PPP to the intermediation server 10 in T302.

[0069] When the relay server 10 receives a printer registration request from the printer 100 in T302, the relay server 10 determines in T304 that an XMPP connection with the printer 100 identified by the PPP has been established, since the PPP included in the printer registration request is stored in association with AT1. Therefore, the relay server 10 does not execute the processes of T104 to T114 in FIG.

[0070] Next, the relay server 10 identifies SA1 stored in association with the PPP included in the printer registration request, and identifies SA2 stored in association with PC2 included in the printer registration request. Then, at T310, the relay server 10 transmits notification information including an account change instruction and the PPP to the SP server 2C. The account change instruction is an instruction indicating that the relay server account stored in the SP server 2C should be changed from SA2 to SA1.

[0071] When the SP server 2C receives the notification information from the relay server 10 in T310, first, in T312, in accordance with the account change instruction included in the notification information, the SP server 2C changes the relay server account from SA2 to SA1. In T312, the SP server 2C further stores the PPP included in the notification information in association with UA2 and SA1.

[0072] Thereafter, the same processes as those from T130 to T142 in Fig. 4 are executed. However, here, UA2 is used instead of UA1. When the SP server 2C receives a service registration request including PPP and the service ID "YYC" from the terminal 6 at T142 in Fig. 4, it transmits a service registration request including SA1, PPP, and the service ID "YYC" to the intermediary server 10 at T320 in Fig. 7 (i.e., T144 in Fig. 4).

[0073] When the intermediary server 10 receives a service registration request from the SP server 2C in T320 (trigger of the process in FIG. 5), the intermediary server 10 uses the service type table 50 to determine that the service ID "YYC" included in the service registration request is associated with the exclusive attribute "Yes" (YES in S10). Next, the intermediary server 10 uses the registration management table 52 to determine that the registered service ID "YYA" having the same service type "Supply" as the service ID "YYC" is associated with PPP (YES in S32). In the transition management table 54, the service ID "YYC" is not stored as a transitionable ID associated with the registered service ID "YYA". For this reason, the intermediary server 10 determines that transition from the service "YYA" to the service "YYC" is not possible (NO in S40), and transmits a registration failure notification to the SP server 2C in T330 indicating that information such as the service ID "YYC" has not been registered (S50). As a result, in T332, the SP server 2C transmits a registration failure notification to the terminal 6, and in T334, the registration failure notification is displayed on the terminal 6.

[0074] As described above, the intermediary server 10 uses the transition management table 54 to determine that transition from the service "YYA" to the service "YYC" is not possible, and does not register the service ID "YYC" in association with the PPP. This makes it possible to suppress inappropriate service transitions.

[0075] (Specific case; Figure 8) Next, referring to Fig. 8, a case following Fig. 7 will be shown. Fig. 8 shows the case where the target SP server is SP server 2B. The initial state of Fig. 8 is the same as the initial state of Fig. 7.

[0076] First, the same processes as T10 to T80 in Fig. 3 are executed. However, here, instead of UA1, a user account UA3 (hereinafter simply referred to as "UA3") is used. As a result, the SP server 2B associates UA3 with the intermediary server account SA3 (hereinafter simply referred to as "SA3") and stores them, similar to T56 in Fig. 3. Also, the intermediary server 10 generates a PIN code C3 (hereinafter simply referred to as "PC3") and associates SA3 with PC3 and stores them, similar to T76.

[0077] The processing of T400 to T420 executed thereafter is the same as the processing of T300 to T320 in Fig. 7, except that UA3, SA3, and PC3 are used. When the intermediary server 10 receives a service registration request from the SP server 2B in T420 (trigger of the processing of Fig. 5), the intermediary server 10 uses the service type table 50 to determine that the service ID "YYB" included in the service registration request is associated with the exclusive attribute "Yes" (YES in S10). Next, the intermediary server 10 uses the registration management table 52 to determine that the registered service ID "YYA" having the same service type "Supply" as the service ID "YYB" is associated with PPP (YES in S32). In the migration management table 54, the service ID "YYB" is stored as a migratable ID associated with the registered service ID "YYA". Therefore, the intermediary server 10 determines that migration from the service "YYA" to the service "YYB" is possible (YES in S40). Then, in T430, the intermediation server 10 transmits the inquiry screen data to the terminal 6 via the SP server 2B (S42).

[0078] When the terminal 6 receives the inquiry screen data from the SP server 2B in T432, it displays the inquiry screen in T434. The terminal 6 accepts the selection of "Migration" from the user in T440. In this case, the terminal 6 transmits the selection result indicating "Migration" to the relay server 10 via the SP server 2B in T442.

[0079] When the intermediary server 10 receives the selection result from the SP server 2B at T444 (YES at S60), it deletes the service ID "YYA" associated with the PPP from the registration management table 52 at T450, and registers the PPP in association with the service ID "YYB" and the type "Supply" (S62).

[0080] As described above, the intermediation server 10 transmits the inquiry screen data to the terminal 6, and switches whether or not to transfer the service depending on the user's selection. This makes it possible to prevent the transfer of the service that is not intended by the user from being executed.

[0081] (Continuation of Figure 8; Figure 9) Next, referring to Fig. 9, a continuation of the case in Fig. 8 will be shown. Using the transition management table 54, the intermediary server 10 determines that the service ID "YYA" and the service ID "YYB" are associated with the same registration process "dedicated ink setting" (YES in S70). Therefore, in T460, the intermediary server 10 transmits a service registration notification including an instruction that no setting is required to the SP server 2B (S82).

[0082] When the SP server 2B receives the service registration notification from the relay server 10 in T460, it transmits a Subscribe request in T470 to the relay server 10. The Subscribe request includes timing information and PPP, but does not include a dedicated setting instruction.

[0083] When the intermediary server 10 receives the Subscribe request from the SP server 2B in T470, it transmits the Subscribe request to the printer 100 in T472 using the XMPP connection (see T144 in Fig. 4). As a result, the printer 100 maintains the dedicated ink setting executed in T214 in Fig. 6. Thereafter, the same processes as T220 to T242 in Fig. 6 are executed, and the consumables automatic shipping service by the SP server 2B is realized.

[0084] Next, in T480, the intermediary server 10 transmits a service stop notification including a setting unnecessary instruction to the SP server 2A (S84). This allows the intermediary server 10 to stop the consumables automatic delivery service provided by the SP server 2A.

[0085] When the SP server 2A receives the service stop notification from the relay server 10 in T480, the SP server 2A transmits an Unsubscribe request to the relay server 10 in T490. The Unsubscribe request includes a PPP. Here, the Unsubscribe request does not include a dedicated release instruction for releasing the dedicated ink setting of the printer 100.

[0086] When the intermediary server 10 receives the Unsubscribe request from the SP server 2A in T490, in T492, it uses the XMPP connection (see T144 in FIG. 4) to send the Unsubscribe request to the printer 100. Because the Unsubscribe request does not include a dedicated release instruction, the printer 100 maintains the dedicated ink setting.

[0087] As described above, when the service ID "YYA" and the service ID "YYB" include the same registration process "dedicated ink setting", the intermediary server 10 transmits a setting unnecessary instruction to the SP server 2B and the SP server 2A. This makes it possible to prevent unnecessary processing, such as the pre-migration SP server 2A causing the printer 100 to cancel the dedicated ink setting and the post-migration SP server 2B causing the printer 100 to execute the dedicated ink setting.

[0088] (Continuation of Figure 9; Figure 10) Next, referring to Fig. 10, a case following Fig. 9 will be shown. Fig. 10 shows a case where the target SP server is SP server 1A. In the initial state of Fig. 10, PPP, YYB, and the type "Supply" are stored in registration management table 52 of relay server 10 (see T450 in Fig. 9).

[0089] First, the same processes as T10 to T80 in Fig. 3 are executed. However, here, instead of UA1, a user account UA4 (hereinafter simply referred to as "UA4") is used. As a result, the SP server 1A associates UA4 with the intermediary server account SA4 (hereinafter simply referred to as "SA4") and stores them, similar to T56 in Fig. 3. Also, the intermediary server 10 generates a PIN code C4 (hereinafter simply referred to as "PC4") and associates SA4 with PC4 and stores them, similar to T76.

[0090] The processing of T500 to T520 executed thereafter is the same as the processing of T300 to T320 in Fig. 7, except that UA4 is used instead of UA2. When the intermediary server 10 receives a service registration request from the SP server 1A at T520 (triggering the processing of Fig. 5), the intermediary server 10 uses the service type table 50 to determine that the service ID "XXA" included in the service registration request is not associated with the exclusive attribute "Yes" (NO at S10). Therefore, at T522, the intermediary server 10 associates PPP with the service ID "XXA" and the type "Remote" and stores them in the registration management table 52 (S12). Next, at T524, the intermediary server 10 transmits a service registration notification to the SP server 1A (S20).

[0091] A service of type "Remote" does not have an exclusive attribute. Therefore, even if PPP and service ID "XXB" are stored in association with each other in the registration management table 52, PPP and service ID "XXA" are also stored in association with each other. In addition, if registration of service "ZZA" of type "Warranty" is requested, if another service "ZZB" of type "Warranty" is not stored in association with PPP, service ID "ZZA" is stored. On the other hand, if another service "ZZB" of type "Warranty" is stored in association with PPP, service ID "ZZA" is not stored.

[0092] Next, a process in which the SP server 1A provides a remote printing service will be described. In T526, the SP server 1A generates a print address PA (hereinafter, referred to as "PA"), which is an email address for causing the printer 100 to execute printing, and stores the PA in association with the UA4, SA1, and PPP. After that, in T530, the SP server 1A transmits a registration completion notification including the PA to the terminal 6.

[0093] When the terminal 6 receives a registration completion notification including the PA from the SP server 1A in T530, the terminal 6 displays the PA in T532. This allows the user to know the PA. Next, the terminal 6 accepts an e-mail sending operation from the user in T540. The e-mail sending operation includes input of the PA as a destination address and selection of an image file representing an image to be printed. In this case, the terminal 6 transmits an e-mail including the PA and the image file to the SP server 1A in T542.

[0094] When the SP server 1A receives the e-mail in T542, it identifies the PPP (see T526) associated with the PA included in the e-mail. Next, the SP server 1A converts the image file included in the e-mail to generate print data having a data format that can be interpreted by the printer 100. Then, in T550, the SP server 1A transmits a notification request including the identified PPP and the URL of the print data to the relay server 10.

[0095] When the intermediary server 10 receives a notification request from the SP server 1A at T550, it identifies the printer 100 from the PPP included in the notification request, and at T552, it sends a print notification including a URL to the identified printer 100 using an XMPP connection (see T144 in Figure 4).

[0096] When the printer 100 receives the print notification from the intermediary server 10 in T552, the printer 100 transmits a data request including the URL in the print notification to the SP server 1A in T560.

[0097] When the SP server 1A receives the data request from the printer 100 in T560, it transmits, in T562, the print data specified by the URL included in the data request to the printer 100. This executes the remote printing service.

[0098] (Service stop sequence; Figure 11) The process for stopping a service will be described with reference to Fig. 11. In Fig. 11, the service "YYB" provided by the SP server 2B is stopped. In the initial state of Fig. 11, UA3, SA1, and PPP are stored in the SP server 2B (see T412 in Fig. 8). PPP, YYB, and the type "Supply" are stored in association with each other in the registration management table 52 of the intermediary server 10 (see T450 in Fig. 9). Also, SA1, PPP, and AT1 are stored in association with each other in the intermediary server 10 (see T110 in Fig. 4).

[0099] When the terminal 6 accepts a login operation from the user, in T600 it transmits a login request including UA3 to the SP server 2B, and in T602 it receives a success notification indicating that the login was successful from the SP server 2B. Next, in T610, the terminal 6 accepts a service stop operation from the user requesting to stop the service "YYB". In this case, in T612, the terminal 6 transmits a service stop request to the SP server 2B. Note that in a modified example, the service stop request may include UA3, PPP, and YYY.

[0100] When the SP server 2B receives the service stop request from the terminal 6 in T612, it identifies the PPP associated with the logged-in UA3. Next, in T620, the SP server 2B transmits an Unsubscribe request including the PPP and a dedicated cancellation instruction to the relay server 10. The dedicated cancellation instruction is an instruction to cancel the dedicated ink setting of the printer 100.

[0101] When the intermediary server 10 receives the Unsubscribe request from the SP server 2B in T620, it transmits an Unsubscribe notification including a dedicated unsubscribe instruction to the printer 100 in T622.

[0102] When the printer 100 receives an Unsubscribe notification from the relay server 10 in T622, it cancels the dedicated ink setting in accordance with the dedicated cancellation instruction included in the Unsubscribe notification. When the printer 100 further receives an Unsubscribe notification, it stops periodically sending consumable information to the relay server 10.

[0103] Thereafter, the SP server 2B transmits a service deletion request including the PPP and the service ID "YYB" to the mediation server 10 at T650.

[0104] When the intermediation server 10 receives the service deletion request from the SP server 2B in T650, it deletes PPP and YYB included in the service deletion request from the registration management table 52 in T652.

[0105] Thereafter, in T660, the SP server 2B transmits a disconnection request including PPP to the relay server 10. The disconnection request is information requesting disconnection of the XMMP connection (see T144 in FIG. 4) between the relay server 10 and the printer 100.

[0106] When the intermediary server 10 receives a disconnection request from the SP server 2B in T660, the intermediary server 10 determines in T670 whether there is another service ID associated with the PPP included in the disconnection request in the registration management table 52. If the intermediary server 10 determines that there is no other service (NO in T670), it sends a disconnection notification to the printer 100. As a result, in T674, the XMMP connection between the intermediary server 10 and the printer 100 is disconnected. On the other hand, if the intermediary server 10 determines that there is another service (YES in T670), it does not send a disconnection notification to the printer 100. As a result, the intermediary server 10 can prevent the occurrence of an event in which communication related to the other service with the printer 100 cannot be executed due to the XMMP connection being disconnected.

[0107] Thereafter, in T680, the SP server 2B transmits a stop completion notification indicating that the registration of the service "YYB" has been stopped to the terminal 6. As a result, in T682, the terminal 6 displays a message indicating that the registration of the service "YYB" has been stopped.

[0108] (Effects of this embodiment) According to this embodiment, when the service requested to be registered by the user is service "XXA" of type "Remote" that does not have an exclusive attribute (T520 in FIG. 10), the intermediary server 10 determines that the service "XXA" can be provided (NO in S10 in FIG. 5) even if another service "XXB" of type "Remote" has already been registered in the registration management table 52 in association with the printer 100. In this case, the intermediary server 10 associates PPP with the service ID "XXA" and stores them in the registration management table 52 (T522 in FIG. 10). On the other hand, when the service for which registration is requested by the user is service "YYC" of type "Supply" having an exclusive attribute (T320 in FIG. 7), if another service "YYA" of type "Supply" has already been registered in registration management table 52 in association with printer 100, intermediary server 10 determines that service "YYC" cannot be provided (NO in S10, YES in S32, NO in S40 in FIG. 5). Thus, intermediary server 10 can switch whether or not to simultaneously provide two or more services of the same service type to the user via the same printer, depending on the service type for which registration is requested.

[0109] (Correspondence) The intermediary server 10, the printer 100, and the PPP are examples of a "server", a "specific communication device", and a "specific device identification information", respectively. The service providing servers 1A to 3B are examples of an "external device". The remote printing service, the consumables automatic delivery service, and the product warranty service are examples of a "first type of service", a "second type of service", and a "third type of service", respectively. In the example of FIG. 7, the service ID "YYC" and the service ID "YYA" are examples of a "first service identification information" and a "second service identification information", respectively. In the example of FIG. 8, the service ID "YYB" and the service ID "YYA" are examples of a "first service identification information" and a "second service identification information", respectively. The service ID "YYB" stored as a transferable ID is an example of a "transferable service identification information". The setting that allows the use of a general-purpose CTG and the dedicated ink setting are examples of a "first setting" and a "second setting", respectively.

[0110] The processes of T144, T200, T320, T420, and T520 in FIG. 4 and the like are examples of processes executed by a "registration request receiving unit". The processes of S10, S32, and S40 in FIG. 5 are examples of processes executed by a "first determination unit". The processes of S12 and S62 are examples of processes executed by a "first storage control unit". The processes of S42 in FIG. 5 and T430 in FIG. 8 are examples of processes executed by a "screen data sending unit". The processes of S84 in FIG. 5 and T480 in FIG. 9 are examples of processes executed by a "first notification unit". The processes of S82 in FIG. 5 and T460 in FIG. 9 are examples of processes executed by a "second notification unit". Sending a dedicated setting instruction at T210 in FIG. 6 is an example of a "first change process". Sending a dedicated release instruction at T620 in FIG. 11 is an example of a "second change process".

[0111] Although specific examples of the present invention have been described above in detail, these are merely examples and do not limit the scope of the claims. The technology described in the claims includes various modifications and alterations of the specific examples exemplified above. Modifications of the above-mentioned embodiments are listed below.

[0112] (Variation 1) In the above embodiment, the intermediary server 10 receives a service registration request from the SP server 1A etc. (T144 in FIG. 4), but instead, the intermediary server 10 may receive a service registration request from the terminal 6, or may receive a service registration request from the printer 100. In this variation, the terminal 6 or the printer 100 is an example of an "external device."

[0113] (Variation 2) The intermediary server 10 may receive a service registration request that does not include PPP from the SP server 1A or the like at T144 in Fig. 4. In this case, the intermediary server 10 identifies the PPP from SA1 included in the service registration request, and executes the process in Fig. 5 using the identified PPP. In this variation, the intermediary server account SA1 is an example of "specific device identification information."

[0114] (Variation 3) Instead of sending a dedicated setting instruction at T210 in Fig. 6, the SP server 2A may cause the terminal 6 or the printer 100 to display a screen indicating that the dedicated ink setting should be changed. Also, instead of sending a dedicated release instruction at T620 in Fig. 11, the SP server 2B may cause the terminal 6 or the printer 100 to display a screen indicating that the dedicated ink setting should be released. In this variation, the process of displaying the former screen and the process of displaying the latter screen are examples of a "first change process" and a "second change process", respectively.

[0115] (Variation 4) The service type table 50 may not include a service ID. In this case, the intermediation server 10 receives a service registration request further including a service type from the SP server 1A or the like at T144 in Fig. 4, and executes the process in Fig. 5 using the service type.

[0116] (Modification 5) The intermediation server 10 may not store the migration management table 54. In this case, if YES in S32 of Fig. 5, the process may proceed to S50. That is, S40 to S44 and S60 to S84 are omitted. Generally speaking, the "memory" may not store the migration-available service identification information.

[0117] (Modification 6) The processes of S42, S44, and S60 in Fig. 5 can be omitted. In this modification, the "screen data transmission unit" can be omitted.

[0118] (Modification 7) The processes of S72, S74, S82, and S84 in Fig. 5 can be omitted. In this modification, the "first notification unit" and the "second notification unit" can be omitted.

[0119] (Variation 8) When the intermediary server 10 receives a disconnection request at T660 in Fig. 11, it may disconnect the XMPP connection regardless of whether there is another service associated with PPP. That is, the process of T670 in Fig. 11 can be omitted. In this variation, the "second determination unit" and the "disconnection unit" can be omitted.

[0120] (Modification 9) The SP servers 3A and 3B can be omitted. In other words, the "third type of service" can be omitted.

[0121] (Modification 10) UA1 to UA4 may all be the same user account, some may be the same user account, or all may be different user accounts.

[0122] (Modification 11) In the above embodiment, the processes in FIGS. 3 to 11 are implemented by software, but at least one of these processes may be implemented by hardware such as a logic circuit.

[0123] In addition, the technical elements described in this specification or drawings exert technical utility alone or in various combinations, and are not limited to the combinations described in the claims at the time of filing. In addition, the technologies exemplified in this specification or drawings achieve multiple objectives simultaneously, and achieving one of those objectives is itself technically useful. [Explanation of symbols]

[0124] 1A to 3B: service providing server, 2: communication system, 6: terminal, 8: Internet, 10: intermediary server, 12, 112: communication I / F, 30, 130: control unit, 32, 132: CPU, 34, 134: memory, 36, 136: program, 50: service type table, 52: registration management table, 54: transition management table, 100: printer, 118: print execution unit, 124: operation unit, 126: display unit

Claims

1. A server, A memory that stores, for each of one or more communication devices, device identification information that identifies the communication device and service identification information that identifies a service currently being provided to a user of the communication device among a plurality of services, in association with each other, the plurality of services includes a first type of service having no exclusive attribute and a second type of service having the exclusive attribute; the exclusive attribute being an attribute that, in a state in which a certain type of service is being provided to a user of a certain communication device, another service of the certain type cannot be further provided to the user of the certain communication device; and a registration request receiving unit that receives a registration request from an external device, the registration request including first service identification information that identifies a first service to be provided to a user of a specific communication device, and specific device identification information that identifies the specific communication device; a first determination unit that determines whether or not the first service can be provided to the user of the specific communication device when the registration request is received from the external device, When the first service is the first type of service, determining that the first service can be provided regardless of whether or not first device identification information and service identification information different from the first service identification information are stored in association with each other in the memory; determining that the first service can be provided when the first service is the second type of service and the first device identification information and service identification information that identifies the second type of service different from the first service are not stored in association with each other in the memory; the first determination unit determining that the first service cannot be provided in a specific case in which the first service is the second type of service and the first device identification information and second service identification information identifying a second service that is the second type of service different from the first service and that is stored in association with each other in the memory; a first storage control unit that stores the first service identification information in the memory in association with the first device identification information when it is determined that the first service can be provided; A server comprising:

2. The memory further stores, for each of the one or more second type services, service identification information for identifying the second type service and migratable service identification information for identifying a migratable service that is a second type service to which the second type service can be migrated, in association with each other; The first determination unit further In the specific case, when the second service identification information and the first service identification information, which is the transferable service identification information, are not stored in association with each other, it is determined that the first service cannot be provided; The server of claim 1, which determines that the first service can be provided when, in the particular case, the second service identification information and the first service identification information, which is the migratable service identification information, are stored in association with each other.

3. The server further comprises: a screen data transmission unit that transmits to the external device inquiry screen data for displaying an inquiry screen when it is determined that the first service can be provided because the second service identification information and the first service identification information, which is the transferable service identification information, are stored in association with each other, the screen data transmission unit being a screen for inquiring of the user of the specific communication device as to whether or not to transfer the second service to the first service; the first storage control unit stores the first service identification information in the memory in association with the specific device identification information when a transition from the second service to the first service is selected on the inquiry screen; The server according to claim 2 , wherein when a selection is made on the inquiry screen not to transition from the second service to the first service, the first service identification information is not stored in the memory.

4. The server further comprises:

4. The server according to claim 2 or 3, further comprising a first notification unit that notifies a second service providing server providing the second service that the provision of the second service to the user of the specific communication device should be stopped when it is determined that the first service can be provided due to the second service identification information and the first service identification information, which is the migrationable service identification information, being stored in association with each other.

5. Each of the first service providing server providing the first service and the second service providing server executing a first change process for changing a setting of the specific communication device from a first setting to a second setting when starting to provide a service to the user of the specific communication device; executing a second change process for changing a setting of the specific communication device from the second setting to the first setting when stopping provision of a service to the user of the specific communication device; The server further comprises: a second notification unit that notifies the first service providing server that the first change process is unnecessary when it is determined that the first service can be provided because the second service identification information and the first service identification information, which is the migratable service identification information, are stored in association with each other; The server according to claim 4 , wherein the first notification unit notifies the second service providing server that the second change process is unnecessary.

6. The server further comprises: an establishment unit that establishes a constant connection with the specific communication device, the constant connection being a connection for executing communication with the specific communication device regarding the provision of a service to the user of the specific communication device; a deletion request receiving unit that receives a deletion request including the first service identification information and the specific device identification information from the external device after the first service identification information is stored in the memory in association with the specific device identification information; a second storage control unit that deletes, when the deletion request is received from the external device, the first service identification information associated with the specific device identification information from the memory; a second determination unit that determines whether or not service identification information different from the first service identification information is stored in association with the specific device identification information when the deletion request is received from the external device; a disconnection unit that disconnects the constant connection with the specific communication device when it is determined that the different service identification information is not stored, and the disconnection unit does not disconnect the constant connection with the specific communication device when it is determined that the different service identification information is stored; The server according to claim 1 , comprising:

7. the plurality of services further includes a third type of service having the exclusive attribute, the third type of service being different from the second type of service; The first determination unit further determining that the first service is capable of being provided when the first service is the third type of service and the specific device identification information is not associated with service identification information that identifies the third type of service different from the first service and is not stored in the memory; 7. A server according to claim 1, further comprising: a first device identification information storing means for storing a service identification information for identifying a service of the third type that is different from the first service, the first device identification information storing means storing a service identification information for identifying the ...

8. A computer program for a server, comprising: The server, A memory that stores, for each of one or more communication devices, device identification information that identifies the communication device and service identification information that identifies a service currently being provided to a user of the communication device among a plurality of services, in association with each other, the plurality of services includes a first type of service having no exclusive attribute and a second type of service having the exclusive attribute; the exclusive attribute being an attribute that, in a state in which a certain type of service is being provided to a user of a certain communication device, another service of the certain type cannot be further provided to the user of the certain communication device; The computer program controls the server computer to include the following units: a registration request receiving unit that receives a registration request from an external device, the registration request including first service identification information that identifies a first service to be provided to a user of a specific communication device, and specific device identification information that identifies the specific communication device; a first determination unit that determines whether or not the first service can be provided to the user of the specific communication device when the registration request is received from the external device, When the first service is the first type of service, determining that the first service can be provided regardless of whether or not first device identification information and service identification information different from the first service identification information are stored in association with each other in the memory; determining that the first service can be provided when the first service is the second type of service and the first device identification information and service identification information that identifies the second type of service different from the first service are not stored in association with each other in the memory; the first determination unit determining that the first service cannot be provided in a specific case in which the first service is the second type of service and the first device identification information and second service identification information identifying a second service that is the second type of service different from the first service and that is stored in association with each other in the memory; a first storage control unit that stores the first service identification information in the memory in association with the first device identification information when it is determined that the first service can be provided; A computer program that functions as a

Images